metodologia wypuszczania Ac

[Michal Moskal]

On Sat, Jun 07, 2003 at 08:41:13PM +0200, Andrzej Krzysztofowicz wrote:
> 
> > 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.

W sensie doinstalować BR czy robić coś poważniejszego?

> Nie wierze, zeby ten etap potrwal krocej niz okolo miesiaca (to dla
> zwolennikow sztywnych terminow).

Też nie sądzę, żeby to krócej trwało.

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

No i tu mamy problem. I pewnie trzeba będzie zrobić L1 i L2.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith : GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h