Jak to w th będzie ( dłuuuuugie )

[Mariusz Mazur]

Wysyłam na pld-devil, bo to jednak dosyć ważna sprawa. Spędziłem na pisaniu 
tego trochę czasu, głównie dlatego, że zależy mi na tym, żeby (a) ludzie 
rozumieli jakie decyzje są podejmowane i dlaczego oraz (b) wiedzieli, że nie 
nie zabieram się za Th 'z automatu' bez żadnego pomysłu jak to ma wyglądać. 
Najbardziej zależy mi na komentarzach odnośnie niejasności poszczególnych 
punktów tekstu (żeby doprecyzował jak coś ma wyglądać i dlaczego), miejscach, 
gdzie można tekst uzupełnić (doświadczenia z pracy nad Ac?), etc. -- ten 
tekst wstawię do cvsu i będę updejtował w razie potrzeby (jak będzie czym), a 
jak już będzie skończony, to gdzieś opublikuję. I mała uwaga: dopisać do 
każdego akapitu "durny pomysł, to się nie uda", to i ja potrafię.



"Zgodnie ze zdrowym rozsądkiem należy wziąć jakąś metodę i wypróbować ją. Gdy
okaże się zawodna, trzeba to szczerze przyznać i wypróbować inną. Ale nade
wszystko trzeba próbować." -- Franklin Delano Roosevelt

JAK TO JEST (I BYŁO) W AC

Gdy tylko buildery Ac zostały ukończone, pełny dostęp do nich został przyznany
każdemu, kto wykazał zainteresowanie. Nie zostały przy tym na chętnych 
nałożone żadne ograniczenia, gdyż, przynajmniej przez pierwsze kilka miesięcy 
rozwoju, nacisk został położony na jak najszybsze zbudowanie wszystkich 
potrzebnych pakietów.  Ale gdy te pakiety zostały już zbudowane i, zamiast 
dodawać nowe, zaczęto aktualizować już istniejące, wtedy zaczęły się 
problemy. Deweloperzy nie mieli dostępu do odpowiedniej części infrastruktury 
(ani nie dysponowali żadnymi rozwiązaniami technicznymi zastępującymi ten 
dostęp), przez co, nawet gdyby chcieli, nie byli w stanie zapewniać 
bezproblemowej integracji swoich zmian z resztą dystrybucji.  Tego typu 
zadania mógł wykonywać tylko Release Manager. Z biegiem czasu proces 
tworzenia Ac był modyfikowany tak, by umożliwić Release Managerowi 
zapanowanie nad zmianami i dopilnowanie, by wszędzie panował
ład. Na chwilę obecną problemów z rozłażącymi się zależnościami i dziwnymi
zmianami raczej nie ma. Zostało to osiągnięte dzięki wprowadzeniu wyraźnego
podziału na deweloperów zajmujących się stabilizacją (i powolnym rozwojem)
dystrybucji oraz tych, którzy głównie skupiają się na testowaniu nowego,
potrzebnego im oprogramowania. W praktyce pewna ilość osób ma uprawnienia do
budowania pakietów do drzewka 'test', podczas gdy tylko cztery osoby mogą
budować do drzewka 'ready'.

Zastanawiające jest, jakim kosztem została osiągnięta ta stabilizacja. Drzewko
testowe ma to ograniczenie, że żaden pakiet nie może zostać z niego
przeniesiony bezpośrednio do drzewka głównego. W tym celu trzeba najpierw
poprosić jedną z czterech uprawnionych osób o puszczenie zlecenia do 'ready', 
a następnie czekać, aż Release Manager pakiet przeniesie. Czy te cztery osoby
rzeczywiście sprawdzają programy, których przebudowanie zlecają, czy też
reagują na prośby niejako automatycznie? A ilu deweloperom wystarczy, że ich
program trafi na jakiś czas do drzewka testowego i nigdy nie chce im się
dopilnowywać, by trafił do 'main'? Niestety nie dysponuję danymi 
statystycznymi z całego okresu rozwoju Ac, ale jeśli przyjąć tezę, że 
stabilizacja została osiągnięta właśnie dzięki niejako sztucznemu 
ograniczeniu ilości paczek, jakie trafiają do głównego drzewka, to czy takie 
rozwiązanie jest pożądane z punktu widzenia dystrybucji?

A nawet jeśli powodem polepszenia jakości Ac nie jest ograniczenie ilości
zmian, ale lepszy nadzór nad tymi zmianami, to należy postawić pytanie, jak
bardzo skaluje się obecne rozwiązanie. Skoro deweloperzy nie mogą bezpośrednio
zajmować się interesującymi ich pakietami, to polega się na tym, że zespół
nadzorujący będzie wszystkiego pilnował (albo będzie się komunikował z resztą
deweloperów). Ale jak wiele osób jest chętnych/ma czas na pilnowanie nieswoich
zabawek i gdzie leży granica liczebności, powyżej której taki zespół nie 
będzie się w stanie skoordynować? O trwającym obecnie przestoju z 
przenoszeniem paczek z 'ready' wiedzą chyba wszyscy, ale z czego wynika to, 
że żadna z pozostałych trzech osób się tym nie zajmuje? Boją się, że mogą o 
czymś nie wiedzieć, a nie chcą popsuć?

JAK BĘDZIE W TH

Do tej pory oficjalnie wydaliśmy tylko Ra i to było dawno temu, zaś Ac jest,
przynajmniej teoretycznie, na ukończeniu. Modelom rozwoju tak Ra, jak i Ac
daleko od doskonałości -- właściwie wszystko zależało i zależy od istnienia
osób, które mają na zbyciu duże ilości czasu i które są gotowe go poświęcić na
robienie czegoś znacznie ponad SOD#1.  Na stały dopływ kloczków nie ma co
liczyć, trzeba wymyślić taki sposób tworzenia dystrybucji, żeby nie byli
potrzebni. Z natury rzeczy Release Manager musi się zajmować wieloma różnymi
rzeczami, ale trzeba ich ilość ograniczyć do niezbędnego minimum, jeśli chcemy
zapewnić sprawny rozwój PLD w dłuższym okresie czasu.

O usprawnieniach technicznych, jakie wprowadziłem do nowej automatyki
builderowej i ftpowej, nie będę pisał -- takie sprawy będzie omawiała
dokumentacja (jak ją wreszcie napiszę). Tutaj się raczej skupię na zmianach
organizacyjnych i powodach, dla których warto je wprowadzić.

Najważniejszą zmianą będzie przywrócenie znanego z Ra trybu umieszczania 
paczek w 'main'. Będzie to polegało na tym, że wszystkie paczki po zbudowaniu 
będą trafiały do 'test' w celu... no cóż -- przetestowania. Te paczki, które 
będą się nadawały do przeniesienia do 'main', będą przenoszone. I tutaj kilka
wyjaśnień.

Po pierwsze, nie ma żadnego problemu z przechowywaniem w 'test' najnowszego
snapshota jakiegoś oprogramowania, z równoczesnym trzymaniem wersji stabilnej,
która to wersja stabilna zostanie przeniesiona do 'main' bez ruszania
snapshota. Nowa automatyka radzi sobie z taką sytuacją bez mrugnięcia okiem.
Oczywiście oznacza to, że upgrejdowanie na ślepo z drzewka testowego nie 
będzie najszczęśliwszym pomysłem, ale aktualizacja do konkretnej wersji nie 
jest żadnym problemem przy użyciu poldka.

Po drugie, nie oznacza to zlikwidowania testowych zleceń, ale różnica jest
taka, że testowe zlecenia będą służyły tylko i wyłącznie do sprawdzania, czy
dany pakiet się poprawnie buduje. Ja testowych zleceń używam tylko do
inkrementalnego sprawdzania, czy moja poprawka działa na danej architekturze
(commit, zlecenie, commit, zlecenie...) i zapewne nie będą one służyły do
niczego innego. Katalog z paczkami zbudowanymi w wyniku takich zleceń jest po
pierwsze ukryty (katalog '.test-builds'), a po drugie nie są w nim generowane
indeksy poldkowe. Same zaś paczki są automatycznie usuwane po kilkudziesięciu
godzinach.

Na pierwszy rzut oka wygląda to tak, jakbym tylko pozmieniał nazwy katalogów w
porównaniu do Ac ('ready' teraz nazywa się 'test', a 'test' -- '.test-builds')
i wyłączył generowanie indeksów dla tego ostatniego (żeby ludziom utrudniać
życie). Żeby zrozumieć na czym rzeczywiście polega ta zmiana, trzeba sobie
najpierw uzmysłowić skąd się wziął obecny podział. Otóż, tworząc nową
automatykę builderową, malekith założył, że paczki gotowe do przeniesienia 
będą trafiały do 'ready', a paczki testowe ('na śmietnik') do 'test'. Tyle, 
że drzewko 'ready' nie zostało stworzone w tym celu -- miało ono za zadanie 
być tylko etapem pośredni przy przenoszeniu wybranych paczek z 'test' do 
'main' -- etapem, na którym jest możliwość sprawdzania poldkiem, czy 
wszystkie zależności są jak trzeba.  Ponieważ na początku prac nad Ac nie 
potrafiłem zmieniać kodu automatyki builderowej, a i nie miałem takiej 
potrzeby (wszystkie zbudowane paczki były i tak od razu przenoszone do 
'main'), więc od samego początku wszyscy zaczęli pracować w ten sposób. I tak 
już zostało. Ten stan został nawet spetryfikowany znacznym zmniejszeniem 
uprawnień większości puszczających.

Ale tak nie miało być. Koncepcja pracy tylko i wyłącznie nad jednym drzewkiem
(tak, jak to było w Ra) jest o wiele sensowniejsza. Najważniejszą kwestią jest
nie zakładanie a priori, że jedno drzewko będzie śmietnikiem (jakim jest 
'test' w Ac), a drugie będzie dla wybranych. Przy podejściu z jednym 
drzewkiem jest wiadome, że każdy pakiet do niego trafiający jest potencjalnym 
kandydatem do przeniesienia do 'main'. Release Manager może np. generować 
sobie listę pakietów starszych, niż miesiąc i wtedy pytać się deweloperów, 
którzy puścili zlecenie, czy paczkę przenieść, czy skasować. Bo i takie 
powinno być jego zadanie -- pilnować, czy deweloperzy o czymś nie zapomnieli, 
komunikować się z nimi, rozsądzać kwestie sporne. I pilnować, żeby praca nie 
szła na marne -- przy jednym drzewku można mieć jasną sytuację z każdym 
jednym pakietem. Nie będzie takich, które zostaną skasowane przez automat i 
nikt tego nie zauważy.

Głównym problemem przy takim podejściu jest rozwiązanie kwestii komunikacji
pomiędzy deweloperami i Release Managerem. To ten ostatni fizycznie uruchamia
program przenoszący paczki, więc musi dysponować dokładnymi informacjami na 
ten temat. Rozwiązanie jest bardzo proste (i właśnie je implementuję) -- 
należy dać deweloperom interfejs, używając którego będą mogli zaznaczać 
pakiety, które chcą, żeby zostały przeniesione. Ze względu na nową 
funkcjonalność poldka, jest bardzo prawdopodobne, że ów interfejs będzie 
automatycznie zaznaczał do przeniesienia pakiety zależne i odmawiał 
zaznaczenia, jeśli pakiety zależne nie będą obecne w 'test' (fizycznie nie 
będzie możliwości przypadkowego popsucia zależności).

Tutaj rodzi się pierwsze pytanie odnośnie szczegółów implementacji -- czy
deweloperzy powinni mieć możliwość zaznaczania tylko tych pakietów, których
zbudowanie sami zlecili? Teoretycznie zawsze trzymaliśmy się zasady, żeby nie
wprowadzać sztucznych ograniczeń i dać każdemu deweloperowi możliwość
ingerencji w dowolną część dystrybucji, ale zarządzanie stabilną linią to nie
commitowanie do cvsu -- tutaj przeniesienie pakietu, który ma jakieś błędy (o
których, przynajmniej w teorii, najlepiej powinien być poinformowany autor
zlecenia) jest czymś, czego powinniśmy się starać za wszelką cenę unikać. Więc
sensownym wydaje się ograniczenie ilości osób mających prawa do przenoszenia
dowolnych paczek tylko do jakiejś małej grupy ludzi. Wstępnie jednak zezwolę 
na wolną amerykankę -- dopiero jeśli okaże się, że deweloperzy nie potrafią 
się sami dogadywać między sobą, to pomyśli się o wprowadzaniu sztywnych 
ograniczeń.

Jest też problem aktualizacji pakietów na builderach. Z doświadczenia wiem, że
puszczanie zleceń z domyślnie ustawioną flagą 'upgrade' nie jest
najszczęśliwszym pomysłem i szybko prowadzi do bałaganu. Na pewno sensowne 
jest ustawienie automatycznej aktualizacji pakietów do tych, które zostają
przenoszone do 'main'. Pytanie, co zrobić z pakietami, które do zbudowania
wymagają nowszej wersji jakiejś biblioteki i nie można ich przenieść do 'main'
(tym samym aktualizując na builderach), gdyż psułoby to zależności w 'main'.
Teoretycznie kilka osób zawsze będzie miało możliwość ręcznej aktualizacji
pakietów na builderach (przy pomocy odpowiedniego zlecenia), ale wtedy na te
osoby spada odpowiedzialność za pilnowanie, czy wszystko jest w porządku. Nie
dysponuję danymi, jak często taka funkcjonalność jest potrzebna, więc możliwe,
że coś takiego może w praktyce działać. Jednak zaimplementowanie w w/w
interfejsie do obsługi ftpa odpowiedniej funkcjonalności, dzięki której
deweloperzy będą mogli słać zlecenia upgrejdu określonych paczek (a interfejs,
jak zwykle, będzie mógł wykonać kilka automatycznych testów, dzięki którym
będzie można łatwo zapobiegać desynchronizacji builderów), nie powinno być
specjalnie trudne. A będzie miało to tę zaletę, że wszystkie zlecenia
aktualizacji będą łatwo obserwowalne dzięki odpowiedniej liście mailingowej.

To, co opisałem powyżej, to tylko plan minimum. Na bazie nowej infrastruktury
można wprowadzać bardzo dużo różnych rozwiązań. Z pomysłów, które można 
wdrożyć praktycznie od razu, chyba najprzydatniejszym będzie lista mailingowa 
na którą będą wysyłane informacje o każdym zaznaczonym do przeniesienia 
pakiecie. Tutaj warto też zastanowić się nad wprowadzeniem odpowiedników 
commit logów, dzięki którym tak osoby śledzące ową listę, jak i Release 
Manager, miałyby wgląd do ewentualnych komentarzy dotyczących danej paczki 
(poprawka błędu security?). Takie rozwiązania zapewniłyby wszystkim 
zainteresowanym deweloperom możliwość śledzenia w czasie rzeczywistym zmian 
zachodzących w dystrybucji, czyli czegoś, bez czego nie wyobrażamy sobie 
korzystania z naszych repozytoriów, ale co jest w bardzo ograniczonym 
zakresie dostępne przy tworzeniu Ac.

Oczywiście można się też zastanowić nad otoczeniem krytycznych pakietów
szczególną 'opieką' poprzez umożliwienie tylko określonym osobom (qboosh ;)
szybkiego przenoszenie paczek typu glibc, kernel, czy też najważniejsze 
demony. Domyślnie takie pakiety musiałyby przeleżeć w 'test' co najmniej 
tydzień (albo dwa). Zresztą teoretycznie można by wszystkie paczki objąć taką 
obowiązkową kwarantanną i przenosić bez leżakowania tylko w drodze wyjątku 
(błędy security). Kwestia do rozważenia.

Jednak najbardziej ambitnym pomysłem jest integracja zarządzania zawartością
serwera ftp z systemem śledzenia błędów. Podstawowa funkcjonalność polegałaby
na tym, że otworzenie błędu dla danego pakietu blokowałoby możliwość
przeniesienia tego pakietu do 'main'. Żeby paczkę przenieść, należałoby
najpierw błąd zamknąć. Błąd byłby też zamykany w przypadku usunięcia pakietu z
ftpa. Miałoby wtedy sens otwieranie błędów security, gdyż byłyby one
automatycznie zamykane przy pojawieniu się nowszego pakietu (przy czym
niekoniecznie zgodnie z prawdą -- pojawienie się nowego pakietu jeszcze nie
znaczy, że ktoś w nim poprawił błąd, ale jest go dosyć bezpieczne założenie).
Ciekawych pomysłów na zapewnienie jakiegoś sensownego kanału, dzięki któremu
zainteresowani mogliby być informowani o błędach klasy security, można by
pewnie zaproponować jeszcze kilka.

Powyższy scenariusz miałby też tę zaletę, że system śledzenia błędów wreszcie
zacząłby być używany do czegoś (a są takie systemy przeważnie całkiem wygodne 
w użyciu, gdyż, jeśli chodzi o samo informowanie, to wszystko może się 
odbywać przy pomocy maili). I, co ważniejsze, po raz pierwszy w historii PLD,
użytkownicy nie służyliby tylko do zjadania łącza na serwerach ftp, ale
rzeczywiście mogliby się do czegoś przydać (już nie wspominając o tym, że
prawie martwy butracker nie wygląda zbyt zachęcająco).

Oczywiście możliwe jest zaimplementowanie niezliczonej ilości drobnych
usprawnień przy używaniu bugtrackera. Maillista z informacjami o błędach to
podstawa, ale równie dobrze zgłoszenie o błędzie w danym pakiecie mogłoby
automatycznie powodować wysłanie informacji do osób, które puszczały dane
zlecenie (tak, nowa automatyka przechowuje takie informacje). Tak samo
zastosowanie kwarantanny, o której wspominałem kilka akapitów wyżej, mogłoby
być zaimplementowane przy pomocy automatycznie otwieranego błędu, który by się
też automatycznie zamykał po określonym czasie (chyba, że ktoś by go wcześniej
zamknął).

PODSUMOWANIE

Zwiększenie udziału deweloperów w tworzeniu danej linii dystrybucji, czy to
przez danie im większej kontroli, czy też dostępu do większej ilości
informacji, jest jak najbardziej pożądane. Powyżej opisałem różne pomysły i
podałem możliwe wariacja dla każdego. Daje to gwarancję, że w razie problemów,
będzie można zawsze spróbować trochę innego podejścia, a nie czekać, aż
wszystko się rozlezie.

I na koniec, żeby było jasne -- jeśli się okaże, że opisane powyżej 
rozwiązania w żadnej kombinacji się nie sprawdzają, to, przynajmniej z 
technicznego punktu widzenia, przywrócenie stanu, jaki jest obecnie w Ac, nie 
będzie żadnym problemem (a i tak używanie tej automatyki będzie znacznie 
wygodniejsze w porównaniu do tego, czego się używa obecnie). Przy czym bycie 
Release Managerem przy ilości pracy, jaka jest wymagana przy obecnym sposobie 
tworzenia dystrybucji, to jest jednak coś, z czego ja najprawdopodobniej 
zrezygnuję. A i pytanie, czy znajdzie się ktoś inny, bo havner się nie 
sklonuje, niektórych ludzi wręcz szkoda przeznaczać do zajęć nietechnicznych 
(a i pewnie nie mieliby na to czasu), a świeża krew w PLD i owszem, jest, 
ale... no cóż -- jest jednak trochę zbyt świeża.



-- 
Każdy człowiek, który naprawdę żyje, nie ma charakteru, nie może go mieć.
Charakter jest zawsze martwy, otacza cię zgniła struktura przeniesiona z 
przeszłości. Jeżeli działasz zgodnie z charakterem wtedy nie działasz w ogóle
- jedynie mechanicznie reagujesz.                 { Osho }