Plan prac nad Ac

[Mariusz Mazur]

(ten tekst zacząłem pisać w sobotę :)

Na ircu doszły mnie słuchy, że w sumie nie wiadomo co ja odnośnie tego Ac 
planuję, a jak już powiedziałem, to się okazało, że się ze mną nie zgadzali. 
No więc poniżej plan wydawniczy Ac:

Kiedyś, gdy Ac nie było na horyzoncie, Ra coś niedomagało, a deweloperzy się 
zaczęli wkurzać, że nie mają gdzie budować pakietów, usłyszałem, że PLD było 
lubiane, bo było w miarę stabilne i w miarę aktualne. I uważam, że w tym 
zdaniu kryje się właściwy sposób tworzenia dystrybucji przy takich zasobach 
ludzkich, jakimi dysponujemy.
A więc plan jest taki, żeby Ac stało się podstawową linią łącząc jednocześnie 
to co jest w Ra i to co jest obecnie w neście. Imho sposób pracy stosowany 
przed mrożeniem Ra (a uskuteczniany teraz np. przez djurbana i adgora) jest 
właściwy. Tzn. jeśli ktoś ma ochotę bawić się snapshotami, to sio na jakiś 
branch, a jak stwierdzi, że to co wyprodukował działa (i sami autorzy też tak 
sądzą, tzn. nie jest to wersja beta), to zapraszamy na head i puszczamy do Ac 
niech poleży trochę w test. *Nie* będzie tak, że na head leży przez dłuższy 
czas rozwalony spec który nie buduje się/nie działa/nie działa na połowie 
architektur. Więc prosiłbym o dobijanie do całkowitych wersji w przypadku 
kluczowych części dystrybucji.
Problem jest jak w takim wypadku zapewnić stabilność. Otóż imho jeśli chodzi o 
stabilność to wszyscy mają głównie na myśli jajko i serwery. No to po prostu 
trzeba będzie przeprowadzić sztywniejsze reguły przy puszczaniu owych 
serwerów. Primo osoba dodająca jakiś patch bierze odpowiedzialność za 
przetestowanie go, a secundo jeśli tylko upgrejd nie jest security, to ma 
powiedzmy dwutygodniowy okres siedzenia w test. Może być?
Teraz dla marudzących o brak nowości i że od stabilizacji jest branch - z 
założenia snapshoty mogą nie działać i nie ma sensu opierać na nich 
jakiejkolwiek gałęzi dystrybucji (nest to luźny zbiór pakietów), a jak ktoś 
ma ochotę na mrożonki to zapraszam do Ra. Ja z Ac mrożonki zamiaru robić nie 
mam, ale też linia dla samobójców to to nie będzie (od tego jest nest). 
Wchodzić będzie wszystko, co ma pełny numerek wersji (żebyśmy byli na 
bierząco), z tym, że kluczowe części dystrybucji będą traktowane z większym 
namaszczeniem. Jak wszyscy wiemy mrożenie Ra aż tak wiele nie dało, bo wpadki 
i tak były (i pewnie będą), więc argument o potencjalnej niestabilności tak 
prowadzonego ac nie jest zbyt mocny (przynajmniej w porównaniu do ra).
Zostaje problem co robimy z upgrejdami kluczowych części dystrybucji. No więc:
- gcc dąży do binarnej kompatybilności, więc jeśli w neście 3.4 sobie posiedzi 
tydzień-dwa i się okaże, że działa na wszystkich arch, to robimy upgrejd (bo 
czemu nie?)
- kernel 2.6 - jak tylko wyjdzie z całkowitym numerkiem, to nie ma *żadnego* 
problemu, żebym cieciwie dorobił dodatkowe małe builderki na których będzie 
panem i władcą, a ów kernel wleci (a) do osobnego katalogu gdzieś w dists/ac 
lub (b) spowoduje, że katalog supported wreszcie się do czegoś przyda.
- postfix 5, exim 12, sendmail 27 - patrz wyżej. Katalog supported czeka 
(jeśli się okaże, że serwerowcy mają ochotę żeby najnowsza wersja siedziała w 
głównym drzewku, to starą można przenieść do supported. Też kein problem)
- glibc - i tutaj widzę jedyny potencjalny problem. Mam nadzieję, że przy 
wydawaniu 2.4 glibcowcy też będą próbowali być binarnie kompatybilni. A jeśli 
nie... no cóż. Nowy glibc szybko nie wyjdzie, a nawet jeśli, to proszę o 
podniesienie ręki tych, którzy odczuli rzeczywistą zmianę funkcjonalności 
przy przejściu z 2.2.5 na 2.3.

Powyższy plan (zwłaszcza część o zasadach korzystania z branchy) jest 
obowiązujący i ewentualność przekonania mnie do jakiś drastycznych zmian 
oceniam na 1 procent. Więc odwołanie co najwyżej do cdg :)


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