PLDWWW: michaloo/DevelopingPLDpl

Wed May 9 11:57:25 CEST 2007

Author: michaloo   Date: Wed May  9 09:57:25 2007 GMT
Module: PLDWWW   URL: http://pld-linux.org/michaloo/DevelopingPLDpl
---- Log message:
initial version

---- Page affected: michaloo/DevelopingPLDpl

---- Diffs:

================================================================
The comment on the change is:
initial version

New page:
= Jak zostać deweloperem PLD =

Ten artykuł jest próbą wyjaśnienia podstaw sposobu rozwijania dystrybucji systemów linuksowych.

== Wymagana wiedza ==

Jako że PLD jest dystrybucją bazującą na systemie paczek RPM, następująca wiedza jest niezbędna, aby kontynuować dalszą naukę:

 * Podstawowe operacje {{{rpm}}}
 * Korzystanie z systemów kontroli wersji takich jak {{{cvs}}} czy {{{svn}}}
 * Obsługa różnic między plikami w oparciu o {{{diff}}} i {{{patch}}}
 * Kompilowanie oprogramowania ze źródeł

== Wewnątrz PLD ==

W porównaniu do innych dużych dystrybucji, PLD Linux nie ma komercyjnego wsparcia. Społeczność deweloperów składa się z ludzi, którzy po prostu potrzebują wykonać jakąś pracę, albo czerpią przyjemność z uczestniczenia w tym, otwartym projekcie (często oba powody są równie istotne).

W swoich wewnętrznych strukturach PLD jest podzielone na linie dystrybucyjne. Aktualnie istnieją trzy:

 * PLD Ra/1.0 (wydana jakiś czas temu)
 * [wiki:AcInfo PLD Ac/2.0] (stabilna)
 * [wiki:ThInfo PLD Th/3.0] (rozwijana)

Każdą linią zarządza osoba zwana kierownikiem wydania (Release Manager). RM zajmuje się utrzymywaniem części infrastruktury PLD, podejmowaniem decyzji, w momencie kiedy deweloperzy sami nie mogą rozstrzygnąć jakiejś kwestii i opiekowaniem się zawartością serwera FTP. 

Inaczej niż RM, większość deweloperów zajmuje się głównie utrzymywaniem pakietów, co zazwyczaj oznacza pracę z plikami {{{spec}}} (będą one wyjaśnione później). Nie ma tutaj wymuszonej odpowiedzialności i każdy może działać z jakimkolwiek pakietem. Jedyną zasadą jest "dotykaj się czegoś, tylko wtedy gdy, jesteś pewien, że wiesz co robisz". Innymi słowy ludzie nie wybierają pakietów do pracy losowo, ale zajmują się tymi, których potrzebują. Może to wyglądać trochę chaotycznie, ale ten model jest całkiem stabilny, ponieważ każda zmiana jest niemal natychmiast weryfikowana. Nie trzeba chyba zaznaczać, że deweloperzy przepadają za takim sposobem organizacji, bo nie potrzebują niczyjej zgody, aby wprowadzać zmiany, których potrzebują. 

== Kwestie techniczne ==

=== Pliki spec ===

Plik {{{spec}}} zawiera metadane i instrukcje budowania wymagane do stworzenia przynajmniej jednego pakietu RPM. Jest to plik tekstowy przeznaczony do pracy skryptu {{{builder}}}, który z kolei obsługuje cały proces, od skompletowania wszystkich niezbędnych źródeł z infrastruktury PLD (lub bezpośrednio z Internetu), do pakowania wyników w instalowalny plik RPM (druga część jest wykonywana przez narzędzie {{{rpmbuild}}}).

Możesz także [wiki:/SpecFiles poczytać więcej o plikach spec].

Wszystkie pliki {{{spec}}} rezydują wewnątrz modułu "SPEC" naszego [:Repositories: serwera CVS]. Moduł ten zawiera także inne specjalne pliki, najbardziej istotny jest skrypt {{{builder}}}.

=== Skrypt builder ===

Skrypt {{{builder}}} jest odpowiedzialny za cały proces montowania pakietu. Zbiera wszystkie potrzebne źródła, sprawdza wymagane zależności, rozpakowuje źródła, kompiluje je i na końcu pakuje rezultaty w instalowalny plik RPM.

Możesz także [wiki:/BuilderScript poczytać więcej o skrypcie builder].

Skrypt ten może zostać uruchomiony przez użytkownika w specjalnej strukturze katalogów w katalogu domowym użytkownika i w znacznym stopniu jest zależny od programu {{{rpmbuild}}} dostarczanego przez pakiet {{{rpm-build}}}.

Ten sam skrypt jest używany przez maszyny stanowiące infrastrukturę PLD do budowania pakietów, umieszczanych później na serwerze FTP.

=== Skrypt adaptujący ===

Skrypt {{{adapter}}} jest narzędziem mającym pomóc deweloperowi w procesie tworzenia czystych plików {{{spec}}}. Wykonuje on automatycznie szereg czynności czyszczących i zajmuje się częstymi błędami pojawiającymi się w plikach {{{spec}}}.

PLD jest bardzo restrykcyjne jeżeli chodzi o pliki {{{spec}}}, więc zaleca się aby korzystać ze skryptu adaptującego w przypadku każdego pliku wysyłanego na listę mailingową deweloperów czy dodawanych do [:Repositories: repozytorium].

Możesz także [wiki:/AdapterScript poczytać więcej o skrypcie adaptującym].

=== Infrastruktura PLD ===

Cały proces tworzenia pakietów odbywa się dzięki klasterowi maszyn budujących pliki RPM z odpowiadających im plików {{{spec}}}. Każda jednostka ma swóje przeznaczenie. Niektóre budują pakiety na konkretne architektury, a inne tworzą pakiety src.rpm zawierające wszystko co jest potrzebne do budowy danego pakietu. Są też węzły służące deweloperom jako środowisko testowe do budowania i sprawdzania pakietów.

Możesz także [:Machines: poczytać więcej o komputerach PLD].

Każda linia dystrybucji ma swój własny zestaw narzędzi do tworzenia pakietów, i własną kolejkę budowania zarządzaną przez grupę zaufanych deweloperów.

[wiki:/ThRequestsRules Zasady wysyłania żądań do budowania pakietów PLD 3.0 (Th) ].

[wiki:/AcRequestsRules Zasady wysyłania żądań do budowania pakietów PLD 2.0 (Ac) ].

== Jak się zaangażować ==

=== Lista mailingowa ===

Powinieneś zacząć od zapisania się na przynajmniej jedną z naszych [:MailingLists: list mailingowych]. Zwłaszcza na {{{pld-devel-en}}} (lub {{{pl}}} dla polskich deweloperów), a także na {{{pld-discuss}}} przeznaczoną na różne dyskusje związane z dystrybucją.

Zauważ, że istnieje także specjalna lista {{{pld-cvs-commit}}}, która nie jest przeznaczona do dyskusji. Zbiera ona natomiast informacje o wszystkich zmianach wprowadzanych przez innych deweloperów na stronie www, czy w repozytorium CVS i SVN.

=== Przygotowanie środowiska pracy ===

Zobacz [wiki:/PreparingWorkingEnvironment przygotowanie środowiska pracy].

=== Praca nad pakietami ===

Zacznij od prostych rzeczy. Wybranie losowego pakietu i aktualizowanie go, może wydawać się dobrym pomysłem, ale w ten sposób prędzej sprowadzisz na siebie kłopoty. Zepsucie aplikacji, od której zależą inne pakiety, nie zaszkodzi dystrybucji samej w sobie, ale zdenerwuje ludzi i utrudni ci dalszą pracę. Spróbuj dodać plik {{{spec}}} dla małej aplikacji, której używasz każdego dnia, albo zaktualizuj istniejący {{{spec}}}  pod nowe wydanie jakiegoś użytecznego narzędzia, bez którego nie możesz żyć.

Zanim stwierdzisz, że jesteś gotowy opublikować swój {{{spec}}}, dwa razy sprawdź sekcję zależności i upewnij się, że pakiet buduje się czysto (na przykład po stworzeniu pliku RPM nie zostają żadne pliki - {{{builder}}} informuje o tym na końcu procesu).

Jeżeli się nudzisz i nie wiesz co mógłbyś zrobić, możesz spróbować zająć się listą [http://cvs.pld-linux.org/PLD-doc/PLD-specs-TODO?rev=HEAD PLD-doc/PLD-specs-TODO], albo generowanymi automatycznie nagłówkami TODO z *.spec: [http://cvs.pld-linux.org/PLD-doc/specs-auto-todo.txt?rev=HEAD PLD-doc/specs-auto-todo.txt]

=== Publikowanie zmian ===

Jako początkujący deweloper nie będziesz miał dostępu odczytu/zapisu do repozytorium CVS, więc będziesz musiał znaleźć kogoś kto sprawdzi twoje zmiany i doda je do repozytorium. Najlepszym wyjściem jest wysłanie maila na listę {{{pld-devel-en}}} (lub {{{pl}}}) i dołączenie do niego "unified diff" twoich zmian zamiast oryginalnych plików (czy wręcz całych, jeżeli jakieś dodajesz) wraz z krótkim opisem tego co zrobiłeś.

Jak tylko jakiś deweloper będzie miał czas przyjrzeć się twoim zmianom, zostaniesz poinformowany o ewentualnych błędach wymagających poprawek i w końcu twoje pliki zostaną opublikowane.

Kiedy twoje zmiany okażą się szczególnie cenne, inni deweloperzy mogą zdecydować się przyznać ci pełne prawa dostępu do naszego repozytorium. Ten proces jest zawsze inicjowany przez kogoś kto ma już prawa odczytu/zapisu. Wysyłanie próśb o ten dostęp nie będzie mile widziane.

Mając już prawa odczytu/zapisu, będziesz mógł regularnie aktualizować CVS. Pamiętaj o sprawdzeniu plików, które dodajesz przez wysłaniem ich do repozytorium. Upewnij się także, że udostępniasz zrozumiały zapis zmian (commitlog). Zapis ten powinien mieć taki format:

{{{- pierwsza zmiana
- druga zmiana
- trzecia zmiana
- jakieś dodatkowe informacje}}}

Nawet jeżeli w twoim commitlog jest tylko jedna wiadomość, poprzedzenie jej myślnikiem poprawi czytelność.

=== Rozwiązywanie częstych problemów ===

 - [:DevelopingPLD/AdvancedDeveloping/FixingAsNeeded: Fixing --as-needed problems]