Quo vadis, PLD?

od redakcji: o PLD słyszał chyba każdy czytelnik 7thGuarda. Dokładny sposób jego tworzenia i zarządzania jest trochę mniej znany, ale nie jest tajemnicą. Czy obecny sposób zarządzania jest dobry, czy zły – i czy należy go zmienić – dyskusja na ten temat trwa już od dawna, i wciąż nie ma ostatecznej odpowiedzi. Dość ważny wydaje się głos jednego z deweloperów PLD, Mariusza Mazura, który przed chwilą opublikował w sieci swój tekst na ten temat. Za jego zgodą publikujemy go i na naszych łamach.

Prawie wszystkie duże dystrybucje Linuksa są sterowane przez firmy za nimi stojące. Nawet Fedora, określana przez RedHata jako „community project”, jest w rzeczywistości raczej poletkiem doświadczalnym producenta. Pomijając mniejsze projekty, jak choćby LinuxFromScratch, za pełnoprawne dystrybucje będące równocześnie kierowanymi przez społeczność swoich twórców, uważa się głównie Gentoo i Debiana. W Polsce dodatkowo dosyć znane jest jeszcze PLD (rekursywny skrót od PLD Linux Distribution, a nie Polish Linux Distribution). Ze względu na techniczne podobieństwa (Gentoo to dystrybucja oparta na źródłach, podczas gdy PLD i Debian używają binarnych pakietów), dwa ostatnie projekty są często porównywane na płaszczyźnie organizacyjnej.
W tym porównaniu Debian jawi się jako dystrybucja dojrzała, stabilna i przewidywalna. Dzięki dużej ilości deweloperów możliwe było sformalizowanie metod rozwoju – za każdy wchodzący w skład dystrybucji pakiet z oprogramowaniem jest odpowiedzialna co najmniej jedna osoba. Żeby owi ludzie nie poruszali się po omacku, istnieje znaczna ilość dokumentów (z Debian Social Contract oraz Debian Free Software Guidelines na czele) określających co, kiedy i jak wolno robić. Sam rozwój cechuje zaś spora powściągliwość – twórcy nie spieszą się dokonywaniem zmian, wychodząc ze słusznego założenia, że każda zmiana niesie ze sobą ryzyko wprowadzenia nowych błędów i to ryzyko należy minimalizować.
Z kolei sposób rozwoju PLD jest postrzegany jako dokładne przeciwieństwo tego, co można zaobserwować w Debianie – chaos organizacyjny, brak jasnych reguł określających kto jest za co odpowiedzialny (jeśli w ogóle ktokolwiek za cokolwiek odpowiada) i, będąca konsekwencją tego wszystkiego, ogólna marna jakość dystrybucji (zwłaszcza brak dopracowania i niska stabilność).
Mogłoby się wydawać, że taki sposób organizacji projektu, w którym zapewnienie wysokiej jakości jest praktycznie niemożliwe, nie ma najmniejszego sensu. Żeby dojrzeć ukrytą tu logikę, trzeba najpierw zrozumieć czym jest i po co jest tworzone (do czego służy) PLD.
Wielu administratorów ceni sobie możliwość praktycznie dowolnego dostosowywania systemu do własnych potrzeb. Preferują oni dystrybucje takie jak Slackware, czy Gentoo, gdzie swoboda działania zaczyna się już na poziomie instalacji poszczególnych programów. W tym kontekście RPM, choć popularny i niepozbawiony zalet, jest jednak narzędziem znacznie ograniczającym pole manewru. A przynajmniej tak się powszechnie uważa.
W rzeczywistości RPM jest narzędziem bardzo elastycznym, trzeba tylko umieć go właściwie użyć. Deweloperzy PLD zawsze starali się ułatwiać sobie pracę właśnie poprzez wykorzystywanie owych możliwości, a wręcz poszerzanie ich tam, gdzie uznali za stosowne.
Rozwiązania techniczne ułatwiają deweloperom pokonywanie napotkanych problemów, ale w interesie samej dystrybucji leży, by zmiany przez nich tworzone były jak najszybciej udostępnianie ogółowi – w przeciwnym wypadku projekt po prostu przestałby się rozwijać. Jest oczywiste, że zachęcać do takiego działania nikogo nie trzeba – rzecz w tym, żeby nie przeszkadzać. Jeśli deweloper stworzył rozwiązanie jakiegoś problemu, bo akurat było mu potrzebne, to trzeba mu zapewnić jak najmniej czasochłonny sposób na dodanie swoich poprawek do dystrybucji, gdyż jeśli tego nie zrobi, to w większości przypadków będzie to ze szkodą dla projektu.
Właśnie z tej filozofii ułatwiania deweloperom życia wynika płaska struktura organizacji PLD – ogólnie rzecz biorąc każdy może dokonywać zmian w dowolnej części dystrybucji i nie ma (prawie) żadnych reguł ograniczających tę swobodę. Oczywiście nie oznacza to, że każdy deweloper może umieszczać na serwerze FTP co tylko mu się podoba, ale szczegóły zostaną wyjaśnione w dalszej części tekstu.
Niektórzy mówią, że PLD to nie dystrybucja, a jedynie zbiór pakietów. W pewnym sensie jest to prawda – PLD to jakby wypadkowa wielu różnych, dostosowanych do indywidualnych potrzeb, systemów, gdzie zmiany są ze sobą synchronizowane, a efekty pracy trzymane w jednym miejscu po to, by oszczędzić deweloperom dublowania pracy.
Sensowność istniejącego sposobu organizacji w niczym nie zmienia efektów – dystrybucja jest w wielu miejscach niedopracowana, nieprzetestowana, błędów nie ma komu poprawiać, deweloperzy nie mają ani czasu, ani możliwości, by testować swoje zmiany na większej liczbie systemów, a aktualizacje na systemach produkcyjnych są tylko dla ludzi o mocnych nerwach. Teoretycznie jest podział na linię stabilną i rozwojową, ale w praktyce ta pierwsza jest już bardzo stara i coraz mniejsza ilość deweloperów się nią interesuje (co bezpośrednio przekłada się na ilość i jakość uaktualnień), a ta druga powinna była zostać zamrożona już dawno temu, ale nie wydaje się, by miało to nastąpić w najbliższym czasie. Deweloperzy o tym wszystkim wiedzą i mają do dyspozycji warsztat, by szybko sobie z ewentualnymi problemami radzić, ale w niektórych zastosowaniach nawet chwila niepotrzebnego przestoju może być kosztowna. Jak łatwo zauważyć, nie ma tu nawet zbytnio miejsca na użytkowników – jeśli komuś odpowiada PLD, to może z niego swobodnie korzystać, ale w przypadku napotkania problemów, może liczyć tylko na siebie, bądź na to, że któryś z twórców będzie miał czas, by zająć się błędem. Nie może to specjalnie dziwić, gdyż trudno oczekiwać wsparcia, nie płacąc za nie, ale z drugiej strony taki Debian dysponuje wystarczającą ilością deweloperów, by móc od nich wymagać reagowania na wszystkie zgłoszone usterki. Co ciekawe PLD posiada szeregowych użytkowników, a spośród tych bardziej aktywnych rekrutuje się nowych deweloperów.
Opisane powyżej problemy są dobrze widoczne z zewnątrz i różni nie związani z projektem ludzie sugerują różne rozwiązania. Nie zdając sobie sprawy z mechanizmów rządzących PLD, nie mogą przewidzieć jakie byłyby rzeczywiste skutki wprowadzenia ich propozycji w życie. Przyjrzyjmy się kilku najczęściej sugerowanym w dyskusjach rozwiązaniom.
Najbardziej radykalnym pomysłem jest likwidacja projektu – po co ciągnąć coś, co nie ma szans na poprawę, a jest dalej rozwijane tylko dzięki sile inercji? Przecież lepiej by było, gdyby obecni deweloperzy dołączyli do większych projektów i tam wdrażali swoje pomysły.
W rzeczywistości PLD jest na swój sposób nieśmiertelne – zawsze pewna grupa deweloperów będzie zainteresowana jego dalszym rozwojem. Nawet jeśli nie w pełnej formie, to chociaż jako zbiór pakietów do innej dystrybucji (czyli to, czym PLD było na samym początku swego istnienia). Jakiekolwiek próby zamknięcia projektu będą miały co najwyżej ten skutek, że deweloperzy stracą dostęp do części infrastruktury (co, oczywiście, nie wprawi ich w zbyt radosny nastrój).
Jedną z kwestii, z których mało osób zdaje sobie sprawę (a co jest tematem samym w sobie i zasługuje na osobny tekst), jest sprawa rozwoju i utrzymywania całej tej niezliczonej ilości programów, jakie składają się na Linuksowy system. Zdecydowana większość ludzi z nich korzystających słyszała najwyżej o garstce liderów najważniejszych projektów i bardzo mgliście uświadamia sobie, jak ogromne ilości osób są w to wszystko zaangażowane. PLD też ma swój udział w tym ogólnoświatowym worku z oprogramowaniem Open Source i choćby to nadaje projektowi swoistą uniwersalną wartość. Cytując Jeffa Johnsona, opiekuna RPMa (nawiasem mówiąc wszyscy wiedzą co to jest RPM, ale ile osób wcześniej słyszało o Jeffie?), mówiącego o planach odnośnie przyszłych wersji: „PLD już to ma od kilku lat, jak zwykle są pierwsi”.
Jako ciekawostkę warto dodać, że jeden z deweloperów praktycznie w pojedynkę tworzy na własne potrzeby PLD oparte na jądrze FreeBSD. Nie publikuje swojej pracy i nie próbuje jej synchronizować z resztą projektu, gdyż byłaby to z jego punktu widzenia strata czasu, jako że tworzy tylko na swoje własne potrzeby. Warto jednak zaznaczyć, że tego typu egzotyczne projekty nie są tylko domeną Debiana.
A właśnie – Debian. Znany i sprawdzony model rozwoju, gdzie wszystko jest jasne i przewidywalne. Wielu ludzi widziałoby ów model w PLD – wreszcie skończyłyby się problemy ze stabilnością, gdyż byłoby dokładnie wiadomo kto za co odpowiada.
Na początku należy sobie uświadomić pewną oczywistą kwestię – to, że ktoś zostanie oficjalnie wyznaczony na opiekuna danego pakietu, nie znaczy, że nagle w magiczny sposób znajdzie czas na pracę nad nim i na reagowanie na błędy zgłaszane przez użytkowników. W przeciwieństwie do Debiana, PLD nigdy nie cierpiało na nadmiar aktywnych deweloperów i nie może sobie pozwolić na strasznie tych, którzy są, a formalne zobowiązania do poświęcania czasu na rzeczy, na które nie mają zamiaru go poświęcać, byłoby postrzegane właśnie w kategoriach straszaka. Próby podniesienia tego tematu na listach dyskusyjnych zawsze spotykają się z twardym sprzeciwem ze strony bezpośrednio zainteresowanych i trudno się dziwić. Tak naprawdę nie leży w interesie deweloperów wprowadzanie jakichkolwiek rozwiązań, które będą im utrudniały pracę nad tą częścią dystrybucji, nad którą akurat muszą (mają ochotę) pracować. Nie oznacza to oczywiście, że obowiązuje nieustająca rotacja i nad każdym elementem systemu pracuje za każdym razem ktoś inny. Niektórzy deweloperzy mają swoje obszary zainteresowań i nie jest żadną tajemnicą kto się czym zajmuje, ale nie są to w żaden sposób stanowiska oficjalne, dające „z urzędu” jakąkolwiek władzę decyzyjną. Po prostu jeśli wiadomo, że ktoś od dłuższego czasu opiekuje się danym programem, to dobrym pomysłem byłoby konsultowanie z taką osobą większych zmian.
Na koniec warto zauważyć jeszcze jedną rzecz – jeśli nawet udałoby się wdrożyć model rozwoju Debiana, to ze względu na zdecydowanie mniejszą ilość deweloperów oraz mniej rozbudowaną infrastrukturę, takie PLD byłoby po prostu zubożałą i gorszą jakościowo wersją pierwowzoru. Sensu taki twór nie miałby ani dla użytkowników (gorsza jakość), ani dla deweloperów (gorsza jakość i zero rekompensaty w postaci ułatwień w dokonywaniu zmian).
Nie da się zlikwidować, nie da się zastosować sprawdzony rozwiązań, to może po prostu czas zacząć mierzyć siły na zamiary. Jeśli deweloperzy przestaliby się zajmować niezliczoną ilością pakietów, a skupili tylko na tej części dystrybucji, która jest najbardziej potrzebna, mogliby zdecydowanie poprawić jej jakość.
Także to rozwiązanie w praktyce okazałoby się kontrproduktywne – samo stworzenie listy najważniejszych pakietów nie oznacza jeszcze, że deweloperzy nagle zaczęliby poświęcać im więcej czasu, natomiast utrudnienia związane z dodawaniem nowych programów spotkałyby się z oporem wszystkich z PLD korzystających (tak twórców, jak i użytkowników, którym nie na rękę byłoby ograniczanie ilości dostępnego oprogramowania).
Podsumowując kilka ostatnich akapitów – próby narzucenia jakichkolwiek sztucznych ograniczeń są z góry skazane na niepowodzenia i dodatkowo mają spory potencjał „uszkodzenia” (jak już ustaliliśmy, zniszczyć się nie da) projektu. Deweloperzy są przyzwyczajeni do swobody, jaką daje im obecny sposób prac nad dystrybucją i wielu uważa to za główną zaletę PLD. Nad ryzykowne rewolucje przedkładają mniej inwazyjne próby poprawy jakości. Zważywszy na fakt, że spora ich część pracuje jako administratorzy i traktuje PLD jako narzędzie ułatwiające codzienną pracę, trudno się im dziwić.
Kwadratura koła. Obecna organizacja projektu implikuje średnią jakość dystrybucji, a próby głębszych zmian najprawdopodobniej tylko pogorszyły by stan rzeczy. Sytuacja bez wyjścia?
Na początku przypomnijmy pewną uwagę z początku tego tekstu – zostało tam stwierdzone, że wprowadzanie zmian w dystrybucji nie jest jednoznaczne z umieszczaniem nowych pakietów na serwerze FTP. I rzeczywiście (może wbrew pozorom) nie jest. Sercem PLD jest jego repozytorium CVS – to w nim deweloperzy umieszczają swoje zmiany i to ono jest niezbędne do pełnego korzystania z zawartości dystrybucji. Gdyby nie było do niego dostępu, to sytuacja przypominałaby używanie Gentoo tylko w oparciu o pewną, dostępną tylko w postaci pakietów binarnych, część dystrybucji, ale bez możliwości użycia narzędzia emerge. O postrzeganej jakości PLD nie świadczy jednak zawartość repozytorium, a to, co znajduje się na serwerze FTP. Utrzymywanie tego serwera jest bardzo ważne z punktu widzenia dystrybucji – gdyby nie dostęp do gotowych pakietów, trzeba by budować każdy element systemu we własnym zakresie, a wtedy równie dobrze można by zacząć używać Gentoo. To właśnie proces zamiany zawartości repozytorium CVS w binarne pakiety umieszczane na serwerze FTP jest tym etapem rozwoju dystrybucji, w którym powinny być wprowadzane rozwiązania pozwalające na poprawę jej jakości.
Niestety łatwiej powiedzieć, niż zrobić. PLD nie jest projektem młodym, ale może się pochwalić tylko jedną wersją wydaną i drugą będącą w trakcie rozwoju. Jak widać, nie było zbyt wielu okazji do próbowania różnych podejść. W rzeczywistości naczelna zasada obowiązująca w PLD, mówiąca że każdy odpowiada za swoje zmiany i jeśli chce mieć coś zrobione, to musi sam się tym zająć (popularny SOD#1, czyli Standardowa Odpowiedź Dewelopera numer jeden – „zrób se sam”), nie ma zastosowania w odniesieniu do zarządzania zawartością serwera FTP. Tutaj wąskim gardłem jest osoba Release Managera (można w uproszczeniu założyć, że jest to przeważnie jeden człowiek). W idealnej sytuacji, Release Manager powinien podejmować decyzje odnośnie tego, co ma się znaleźć w danej linii dystrybucji, nadzorować jej wydawanie i wychwytywać niedociągnięcia. Niestety używa zbyt prymitywnych narzędzi, przez co poświęca znaczne ilości czasu na ręczne wykonywanie czynności, których wykonywanie należałoby zautomatyzować, bądź oddać pod nadzór reszty deweloperów. Oczywiście to wąskie gardło powinno zostać zlikwidowane, niestety próby wprowadzania bardziej radykalnych zmian, gdy dana linia jest rozwijana już przez dłuższy okres, mogą być niebezpieczne. Dodatkowo to właśnie Release Manager jest osobą, której najbardziej zależy na wprowadzeniu usprawnień i która ma doświadczenie potrzebne przy ich opracowywaniu, ale niestety równocześnie zasoby czasowe, które mogłaby na to poświęcić, są pochłaniane przez codzienne obowiązki związane z utrzymywaniem swojej linii dystrybucji.
Dlatego też przed rozpoczęciem właściwych prac nad linią 3.0 PLD (zgodnie z tradycją, biorącą nazwę od symbolu oznaczającego jakiś pierwiastek chemiczny – w tym wypadku jest to Th) zostanie przygotowana infrastruktura, dzięki której deweloperzy będą mieli większą kontrolę nad tym procesem, a Release Manager nie będzie musiał niepotrzebnie tracić czasu i będzie mógł się skupić na właściwej pracy. Na dodatek zostanie ona napisana w taki sposób, by umożliwić późniejszą bezbolesną integrację z nowymi jej elementami. Możliwości są spore – dokładna lista propozycji zostanie opisana w osobnym tekście – z najciekawszych pomysłów warto wspomnieć o wdrożeniu użytkowników w proces aktywnego testowania dystrybucji.
Plany są ambitne, ale konkretne i dobrze przemyślane. Problem w tym, że ktoś będzie musiał to wszystko napisać i wdrożyć.
Archiwalny news dodany przez użytkownika: mmazur.
Kliknij tutaj by zobaczyć archiwalne komentarze.