Author: mmazur Date: Mon Mar 7 16:41:41 2005 GMT
Module: PLD-doc Tag: HEAD
---- Log message:
- oryginalna wersja; trza wyciąć błędy odnośnie ac i doprecyzować kilka
rzeczy
---- Files affected:
PLD-doc:
PLD_3.0_plany.txt (NONE -> 1.1) (NEW)
---- Diffs:
================================================================
Index: PLD-doc/PLD_3.0_plany.txt
diff -u /dev/null PLD-doc/PLD_3.0_plany.txt:1.1
--- /dev/null Mon Mar 7 17:41:41 2005
+++ PLD-doc/PLD_3.0_plany.txt Mon Mar 7 17:41:36 2005
@@ -0,0 +1,239 @@
+"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.
+
+
+# vi: formatoptions=a
================================================================
_______________________________________________
pld-cvs-commit mailing list
pld-cvs-commit@pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
