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

[Jakub Bogusz]

On Sun, Mar 06, 2005 at 11:28:47PM +0100, Mariusz Mazur wrote:
> 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.

Jednego pakietu tak, wymaganych przez niego innych pakietów (bez ścisłej
zależności od wersji) już nie - albo mamy loterię, albo
choose_equivalents_manually i wnerwiający quiz z kilkunastoma+ pytaniami.

> 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.

Nie wiem jak z serwerem na ftp.* - ale np. pure-ftpd nie pozwala wejść
do katalogów .[!.]*, więc nawet nie ma jak zobaczyć, co się zbudowało ;>

> 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'.

No niekoniecznie. test zostało śmietnikiem nieco później, przy
wyłączeniu tagowania przy budowaniu.
Przedtem IIRC zdarzało się przenoszenie z test do ready.

> 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,

Co najmniej kilka razy w miesiącu dla grup > kilka pakietów.
Pary albo trójki pakietów częściej (np. jakieś dclib+już-nie-dcgui, albo
sip+PyQt+PyKDE).
Grupy po kilkadziesiąt pakietów raz na parę miesięcy.

> 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.

> 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ąć.

I zgłaszając błąd typu "nie działa pr0n patch" można zablokować
uaktualnienie security ;>

> 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.

[...]
> 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.

I to jest teraz spory problem.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/