Branch 1.0

[Tomasz Kłoczko]

On Sat, 24 Nov 2001, Robert Kurtys wrote:
[..]
> > W zasadzie nie. Jest jedna tylko regóła: nie wprowadzamy na razie na HEAD
> > zmian które nie powinny wejść do 1.0. Jeżeli ktoś chce jakiś bardzo
> > świerzymi rzeczami się zająć to zakłada sobie barancha w danym pakiecie
> > (tak jak to jest teraz z przykładowo z kernelem). Po wypuszczeniu 1.0 tego
> > typu branche bendą w pierwszym rzędzie integrowane z HEAD.
> 
> 
> wow!!!!!
> 
> to to jest rownoznaczne z tym ze wszystkie ustalenia dotyczace pakietow
> majacych wejsc do PLD 1.0 i ich wersji maja obecnie zastosowanie do HEAD
> i do mrozonki nie sa potrzebne dodatkowe buildery
> 
> czy moze znowu cos pomylilem?

Dodatkowe buildery bedą potrzebne żeby przyszykować taki "kernel 2.4
migration kit". Po zamknieciu 1.0 role tych dwuch grup builderów sie
odwrócą. Na starych bendą przebudowywane tylko pakiety z jakimiś
poprawekami (i tu się raczej mało będzie dziać), a na nowych niemal
momentalnie będzie można zacząć ruszaniem dalej z czołem zmian. Tak czy
inaczje mam naprawdę wielką prośbę o to żeby wytrzymać jeszcze troche i
skupić się na tym co jest robione pod stable. Chodzi o to że nie jat nas
dużo. W porównaniu do rozmairów zespołu Debiana jest nas o więcej niż
rząd welkości mniej. Oni w tej sytuacji mogą sobie pozwolić na komfort
ciągnięcia aktywmnie kilku nitek. W naszym przypadku byłaby to już jednak
rozrzutność.

Ad rem: głównym zadaniem w tej chwili jest w pierwszym podejściu usunięcie
wszelkich błędów w pakietach które blokują ich prawidłowe budowanie. Za
kilka dni ruszy BTS na bugs.pld.org.pl jaki robi Paweł i wtedy będzie to
nawet łatwiejsze do zbierania sztuka po sztuce. W międzyczasie powinna być
skompletowana lista tego co jest do wyczyszczenia (i prawdopodonbnie
będzie dobrze jak co kilka dni taka baza bedzie się poajwiać na liscie).
Tutaj jeżeli ktoś może pomóc w czymś Pawłowi to prosze też o takie
wsparcie. Potem powinniśmy dać sobie z tydzeń, dwa na jeszcze dalsze
poprawianie jakiś błędów na poziomie działnia już poprawnie budujacych sie
pakietów. To czy ma to być tydzeń czy dwa, mniej czy więcej pozostawiłbym
na czas kiedy bedziemy mieli wyczysczone pakiety na poziomie ich
budowanai. W staniej fazie takeigo czyszczenie pakeitu które bedą trudne
do wyczyszczenia beą ulegać rugowaniu z zasobów wystawianych na ftp. To
będzie już dość radykalne ale w ten sposób jedynie w kontrolowalnym czasie
można bedzie to skończyć. Do tego czasu etykietę *STABLE* w cvs należy
traktować jako obowiazujacą dla 1.0. Ergo: to co w ostaniej fazie ulegnie
oddzieleniu ze względu na niemożlość usunięcia błędów budowania taka
etykietę poprostu straci.
Tak czy inaczje unikajmy jednak konkretnych terminów boe te znacznie 
ciężej określić niż warunki jakie mają spełniać zasoby po to 
zeby wcisnąć w te ramy zasoby jakie mamy.

Jeżeli w międzyczasie pojawią się nowe wersje jakiś pakietów wypuszczone
przez maintainera to jest możliwe włączenie tego do tego co teraz robimy.  
Warunek: nowa wersja zawierać ma przedewszystkim poprawki. Decyzję co do
tego czy włożczyć jakąś nową wersję czy nie pozostawiam każdemu kto na
taką zmianę się zdecyduje. Mamy wszystko w cvs, a od pewnego czasu ze
względu na to że nie są usuwane tary z SOURCES/Attic (po powiekszeniu
zasobów dyskowych) cofniecie się do poprzedniej wersji jest niemal
momentalne poprzez tylko przestawienie etykkiet. Chodzi o to że włączajac
taką kolejną wersję którą usuwa jakieś błędy likwidujemy je w tym co
kompletujemy. Tak przykładaowo było dzisiaj w moim przypadku z openslp i
gftp. Od dłuższego czasu (z wyjątkiem kde*) o ile ja sam decyduję się na
nowa wersję pakietu pzreglądam szczegółowo changelog pakietu i staram się
świadomie podjąć decyzję co do tego czy to ma wejść czy nie i to samo
zalecam każdej innej osobie której przyjdzie podjąc tego typu decyzję co
do wrzucenia nowej wretrsji. Tak jak mówiłem to oczywiście nie musi
oznaczać wsztrzymania zmian wątpliwych z punktyu widznia PLD 1.0 ale
potrzebnych z punktu widzenia własnych zmian. Niemniej tego typu zmiany
muszą raczje od tego momentu wchodzić na brancha. Dlatego na brancha żeby
możliwie nie utrudniać pobierania źródeł tego co w tej chwili
najważniejsze czyli tego co ma wejść do 1.0.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*