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 [EMAIL PROTECTED] __________________________________________________________ nie pytaj co inni zrobili dla pld, pomysl ile sam zrobiles
