Dodatek A

A.1 Wysyłanie łatek

Chcesz wysłać łatkę poprawiającą znaleziony błąd? Przeczytaj Documentation/SubmittingPatches, oraz zwróć szczególną uwagę na SECTION 3 - REFERENCES. Znajdują się tam odnośniki do dokumentów, z którymi należy się zapoznać przed wysłaniem łatki. Pamiętaj o wyłączeniu zawijania tekstu w kliencie poczty. Niektóre programy pocztowe np. Thunderbird lubią zmieniać białe znaki na inne białe znaki. Może to powodować problemy przy ich nakładaniu. Jednym z rozwiązań problemu jest instalacja rozszerzenia do szyfrowania listów ( na przykład enigmail ), która z reguły rozwiązuje takie problemy (jeśli chcesz używać Thunderbirda do wysyłania łatek, polecamy lekturę http://mbligh.org/linuxdocs/Email/Clients/Thunderbird).
Jeżeli chcesz wysłać całą serię łatek, to lepszym rozwiązaniem jest wykorzystanie skryptu Skrypt.
Jeżeli nie chcesz się męczyć z rozgryzaniem wszystkiego, zamieścimy krótką instrukcję:

• zainstaluj programy sendmail i mutt
• na początku skryptu wpisz „sudo /etc/init.d/sendmail start” a na końcu „sudo /etc/init.d/sendmail stop” - ograniczy to czas otwarcia potencjalnej dziury w systemie (sendmail ma bardzo długą listę luk).
• do pliku .muttrc wpisz „set realname=’Imię Nazwisko’” i „set from=jakiś_adres@email”
• w 99 linijce skryptu zmień adres -bcc na swój
• zmień nazwę swojego hosta na nazwę bramy, pozwoli to pozbyć się błędu otrzymywania listów zwrotnych o treści:

----- The following addresses had permanent fatal errors -----
<ktoś@gdzieś.com> (reason: 553 5.1.8 <ktoś@gdzieś.com>... Domain of sender address ktoś2@gdzieś2.com does not exist) [..]

Teraz trzeba utworzyć plik, który zostanie wysłany jako [PATCH 0/x], o następującym formacie:

Subject: Jakiś temat
To: adres_jakiejś@listy.com
CC: adres_jakiegoś@odbiorcy1.com, adres_jakiegoś@odbiorcy2.com
Opis łatek, diffstat etc.

Również na początku każdej łatki dodajemy podobny nagłówek. Następnie tworzymy plik z serią łatek (taki sam jak do quilt) i już możemy wysłać wszystkie łatki:

$ 42_send_patch_mail.sh -d plik_z_wiadomością.txt -s plik_z_serią_łatek

Ciekawym skryptem umilającym wysyłanie łatek jest również SendPatchset. Jego niewątpliwą zaletą jest to, że nie wymaga instalacji programów sendmail i mutt. Wystarczy tylko stworzyć plik kontrolny o treści:

SMTP: adres_serwera.smtp.z.którego@korzystamy.com
From: Imię i Nazwisko <nasz_adres@email>
To: Adresat1 <adres1@gdzieś.com>
Cc: Adresat2 <adres2@gdzieś.com>
Cc: Adresat3 <adres3@gdzieś.com>
Subject: [PATCH 1/n] Opis pierwszej łatki
File: ścieżka-do-łatki
Subject: [PATCH n/n] Opis ostatniej łatki
File: ścieżka-do-ostatniej-łatki

Następnie wysyłamy łatki:

$ sendpatchset control

A.2 System testowy

Nasz system testowy powinien być odseparowany od systemu, na którym normalnie pracujemy. Nie powinniśmy również montować w nim żadnych partycji z systemu stabilnego. Dzięki temu, w razie wystąpienia jakiegoś poważnego błędu w systemie plików lub innym podsystemie jądra nasz system stabilny nie powinien ucierpieć ( czasem błąd jądra może spowodować utratę danych ). Jeżeli nowe jądro zniszczy nasz system testowy, to znaleźliśmy poważny błąd, o którym powinniśmy powiadomić deweloperów systemu. Kolejną rzeczą, o której warto pamiętać jest to, że możemy pracować na innym systemie z poziomu systemu stabilnego. Wystarczy przygotować i zamontować sobie jakąś partycję , a następnie przy pomocy programu chroot zmienić "korzeń" drzewa katalogów. Więcej na temat tego programu możecie przeczytać na jego stronie man. Teraz możemy pobrać, skonfigurować, skompilować i zainstalować nowe jądro. Dobrze jest wykorzystać jakiś skrypt, który wszystkie te operacje wykona za nas. Oszczędzi to czas, pozwalając na zajęcie się inną ciekawą rzeczą. Gdy znajdziemy chwilę czasu, możemy zrestartować system i przejść do systemu testowego.

Przy wyborze dystrybucji służącej nam za system testowy, powinniśmy kierować się tylko i wyłącznie wygodą. Dystrybucja ta powinna nam ułatwić pracę, a nie przysparzać dodatkowej. Gdy testujemy nowe wersje jądra, chcielibyśmy też testować jego nową funkcjonalność, dlatego fajnie jest, gdy dystrybucja ta oferuje nowe wersje narzędzi i bibliotek. Dobrym wyborem jest testowa wersja Debiana - posiada aktualne wersje narzędzi, a zarazem starsze wersje gcc (niestety nie wszyscy deweloperzy sprawdzają czy ich kod działa po skompilowaniu inną wersją gcc niż ta dostarczana razem z ich ulubioną dystrybucją). Fedora Core posiada bardzo dobre wsparcie dla SELinuksa i wszystkich nowości, które oferują najnowsze wersje jądra.

A.3 KLive

KLive jest narzędziem, dzięki któremu deweloperzy Linuksa mogą się dowiedzieć jak długo dane drzewo było testowane. Dlaczego warto go używać? Linus Torvalds tak zaanonsował wydanie 2.6.15-rc5:

„There’s a rc5 out there now, largely because I’m going to be out of email contact for the next week, and while I wish people were religiously testing all the nightly snapshots, the fact is, you guys don’t.”

Deweloperzy nie są jasnowidzami i nie wiedzą ile osób i jak długo testowało konkretne wydanie - czasami zdarza się sytuacja, że wszystko działa jak należy i nikt nie zgłasza żadnych błędów - wtedy opiekun drzewa nie ma żadnej pewności, czy ktokolwiek testował dane wydanie. Jeżeli chcesz używać KLive, to na początku proponuje odwiedzić stronę projektu KLive. Można na niej znaleźć informacje o sposobie instalacji i działania programu. Instalacja programu jest bardzo prosta, wystarczy zainstalować wymagane pakiety, a następnie pobrać i uruchomić skrypt (sh klive.sh —install).

A.4 Jak zostać deweloperem Linuksa?

Czasami na LKML pojawia się to pytanie (ja na nie nie będę odpowiadał z prostego powodu nie jestem deweloperem), dlatego Greg KroahHartman napisał krótki dokument na ten temat. Jeżeli chcesz poznać odpowiedź na to pytanie, to po prostu przeczytaj Documentation/HOWTO :).

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-Share Alike 2.5 License.