plan freezowania ac?

[Piotr Szymanski]

Hi,
Po dluzszej rozmowie spidi wymogl na mnie wymyslenie jakiegos projektu wydania 
ac. Dlaczego na mnie? Bo przez moje kde nie mozna rozpoczac prac nad wydaniem 
dzisiaj.
Taka jest propozycja, podkreslam, ze to tylko propozycja i ze nie podejmuje 
sie jej wprowazac bo czeka mnie matura i zdaje sobie sprawe z tego ze nie 
bede mial czasu na pld za duzo,  poza zrobieniem kde 3.2.
<begin>
01.02 - 1st freeze, to bedzie podstawa do pozniejszego ac, dopuszczalne sa 
updaty pakietow nie psujace dzialania dystrybucji (czyli kompatybilne wstecz 
binarnie), jednoczesnie trwaja prace nad szlifowaniem pakietow i updatowaniem 
rzadko uzywanych specow oraz wyczyszczeniem otagowanego 01.02 
PLD-update-todo, oczywiscie pod warunkiem ze te updty nie lamia przyjetej 
zasady kompatybilnosci ABI (zlamanie kompatybilnosci zrodlowej dopsuzczam 
jeszcze w tym momencie)

15.03 - reality check, sprawdzamy czy to co zostalo po miesiacu pracy nadaje 
sie do uzywania i czy liczba snapszotow zostala maksymalnie ograniczona oraz 
czy snapszoty ktore pozostaly dzialaja na tyle stabilnie, zebywlaczyc je do 
wydania; jesli nie - opoznienie 2nd freeze o max 2 tyg. jesli do tego momentu 
sie nie uda, czyscimy buildery i wypierdzielamy pld, bo jak 40 typa nie umie 
naprawic bledu w 2 miesiace to to panowie jest burdel a nie dystrybucja.

20.03 - 2nd freze, dopuszczalne sa jedynie upgrady pakietow ktore sluza 
poprawie bezpieczenstwa i ew. poprawiajace jakies ogromne bledy 
uniemozliwiajace uzytkowanie, ktore zostaly przeoczone wczesniej, tworzone 
jest koncowe dystro, poprawiane ew. niedorobki w budowaniu. 

ODTAD DOPIER ZACZYNA SIE FREEZE W ROZUMIENIU TEGO SLOWA JAKIE BYLO W RA. 
FREEZE TRWA 3 MIESIACE NIE 6! 

05.04 - reality check, sprawdzamy czy efekt koncowy po 2nd freeze nadaje sie 
do wydania, jesli nie - sprawdzamy przyczyny i staramy sie wyeliminowac bez 
upgradowania do wyzszych wersji; jesli nadaje sie do wydania to zamrozenie 
stanu pakietow na ftp i przygotowywanie instalatora

10.04 - pld 2.0rc1 udostepnione betatesterom

01.05 - rozpoczecie poprawiania bledow wykrytych w czasie testow,

14.05 - koniec betatestow

20.05 - koniec poprawiania bledow

21.05 - reality check, jesli nie ma bledow krytycznych oraz takich 
wystepujacych w rzadko uzywanych/malo waznych pakietach i wtedy tylko gdy sa 
to pojedyncze przypadki (np. jakis nie uzywany modul cpan i jakas stara gra, 
czyli 2 pakiety na 6 tysiecy, ktore mozna wydac jako updaty) przechodzimy do 
wydawania finala, jesli nie powtarzamy cykl z rc2 i betatestami

22.05 - przygotowywanie iso z isntalatorem oraz notki prasowej

23.05 - wydanie PLD 2.0 (ac)
<end>

Ten plan jest na pewno bardziej realistyczny niz optymistyczny, przy czym 
zaklada kilka rzeczy:
1.) glibc 2.3.3 ktory bardzo by sie przydal wyjdzie albo przed 01.02 albo 
bedzie binarnie kompatybilny wstecz
2.) jesli glibc 2.3.3 wyjdzie po 01.02 to pld 2.0 nie bedzie mialo domyslnie 
wlaczonego nptl, bo tenze psulby kompatybilnosc ABI 
3.) od 2nd freeze przydaloby sie zeby Release Manager kontrolowal kazde 
zadanie wyslane na buildery, przydaloby sie takze zamrozenie head na miesiac 
tak zeby kazda zmiana musiala byc zatwierdzana przez grupe ludzi najbardziej 
zaangazowanych w wydanie, tak zeby nie zepsuc calosci, to jest wniosek po 
znajomosci sposobu pracy w kde. rozumiem ze ten miesiac to dlugo i jesli by 
sie miala ukazac jeszce rc2 to wogole za dlugi freeze. z tego powodu nie 
umiescilem tego w planie a jedynie tak rzucam dodatkowo.
-- 
Piotr Szymanski
djurban w pld-linux.org