metodologia wypuszczania Ac

[Michal Moskal]

On Sat, Jun 07, 2003 at 09:04:26PM +0200, Andrzej Krzysztofowicz wrote:
> > > 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?
> 
> Rozmaicie.
> Np. chcesz przebudowac z nowa wersja jakiejs biblioteki.
> Najpierw musisz przebudowac te biblioteke.
> Musisz te biblioteke zainstalowac.
> Ale nadal masz na builderze tuzin pakietow skonsolidowanych ze stara wersja
> biblioteki - musisz je wszystkie wyinstalowac, przebudowac i ponownie
> zainstalowac.
> Te pakiety moga miec wzajemne zaleznosci - wymusza to kolejnosc budowania
> i instalacji.
> Wszystko to tzreba zrobic synchronicznie na wszystkich builderach (chyba, ze
> ktos lubi wielokrotnie powtarzac te sama prace).
> 
> To tylko jeden z przykladow. Dosc czesty.

To wiem. Chodziło mi o to, czy coś innego niż doinstalowanie BR
występuje w 10%, 1% czy 0.1% pakietów. Po prostu puszczając zlecenia na
buildery nestowe nigdy się nie spotkałem z jakimiś innymi problemami,
ale fakt, że dużo pakietów nie puszczam.

Pozatym builder ma teraz opcję, że instaluje zbudowane pakiety. Tylko,
że to działa w 1/2 przypadków ze względu na zależności.

Pytam dlatego, że doinstalowywanie i wywalanie BR może być rozwiązane
automatycznie (właśnie produkuje skrypty do tego). Jeśli zrobić tak jak
mówiłem (nie wywalać po budowaniu wszystkiego, ale tylko co co jest
zbędne dla następnego), to wydaje mi się, że można to zastosować na
builderach produkcyjnych. 

No i jeśli budowanie będzie tylko kwestią puszczania zleceń (bez ssh
builder poldek -i ...), to powinno to pujść *znacznie* szybciej.

> > > 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.
> 
> Albo nie wszystko wypuszczac w najnowszej wersji. Mrozenie head? ;)

Po co mrozić, można przecież otagować, albo na branchu robić. Pozatym
takich pakietów nie powinno być dużo.

> Poza tym, jesli takimi decyzjami ma sie zajmowac CDG, to jest to czysta
> strata czasu.

IMHO CDG może zatwierdzić tylko ogólne założenia.

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