metodologia wypuszczania Ac

Andrzej Krzysztofowicz ankry w green.mif.pg.gda.pl
Sob, 7 Cze 2003, 20:41:13 CEST


> Przed wypuszczeniem Ac musimy sobie odpowiedzieć na kilka pytań, np. o
> zestaw pakietów lub krąg odbiorców (który determinuje częściowo zestaw
> pakietów) etc
> 
> Zupełenie niezależną sprawą jest samo techniczne podejście do
> wypuszczania dystrybucji.
> 
> Ja osobiście to widzę tak (Uwaga, nie napiszę tu raczej nic odkrywczego):
> 
> 1. wybieramy RM (Release Manager) (jednego lub kilku, ale tak by się
>    mogli dogadać)
> 
> 1,5. RM robi bootstrap pakietów na builderach Ac.
>    
> 2. RM puszcza na builder wszystkie pakiety z repo (z wyj.
>    niedystrybuowalnych etc), tagując je "AC-tag" (po udanym zbudowaniu). 

Nie wiem, czy wszyscy zdaja sobie sprawe, ze dla wielu pakietow trzeba pred
ich puszczeniem zmodyfikowac srodowisko.
Nie wierze, zeby ten etap potrwal krocej niz okolo miesiaca (to dla
zwolennikow sztywnych terminow).
   
>    Pakiety są puszczane domyślnie z HEAD, chyba, że zdecydujemy że z
>    dany pakiet z jakiegoś innego brancha. Takich wyjątków nie będzie
>    raczej dużo, należy je gdzieś spisać, żeby łatwiej wykonać krok 4.
> 
>    Jeśli pakiety są niekrytyczne (to zależy od kręgu odbiorców), i się
>    nie budują, to nie mają taga i nie wchodzą do Ac. Krytyczne pakiety
>    muszą być poprawione i w końcu się zbudować.
> 
> 3. Testowanie i poprawianie. Zazębia się ono w czasie z krokiem 2.
> 
> 4. Ponowne puszczenie wszystkich pakietów, które się zmieniły i RM
>    decyduje, że zmieniły się na lepsze na builder i przesunięcie AC-tag.
> 
> Kroki 3 i 4 można powtarzać do skutku (aż RM? CDG? powie dość).
> 
> Jak widać nie ma tu żadnej mrożonki, developerzy robią co chcą, ale
> oczywiście zalecane jest skupienie się na ,,3.''. W commitlogach można
> by zaznaczać, że dana zmiana nie jest dla Ac, lub trzeba przemyśleć czy
> dla Ac.

Jest problem, gdy masz w dystrybucji wazne pakiety X i Y wymagajace
biblioteki L, a jeden z tych pakietow, np X, (jego wersja z HEAD) wymaga
najnowszej wersji biblioteki podczas gdy drugi (Y - zadna wersja lub zadna
stabilna wersja) nie wspiera najnowszej wersji biblioteki L.
Decyzja, co w takiej sytuacji zrobic (np. wersje bibliotek na HEAD/branchu)
powinna nalezej jednoosobowo do RM.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry w mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology



Więcej informacji o liście dyskusyjnej pld-devel-pl