metodologia wypuszczania Ac

[Andrzej Krzysztofowicz]

> 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

Miedzy 1% a 10%, ZTCP.
Chyba, ze liczysz BR pakiet, ktory czeka w kolejce do zbudowania...
(kolejnosc wyslania zlecen != kolejnosc budowania)

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

Nie jestem pewien, czy powinien. A jak to co sie wlasnie zbudowalo jest na
tyle skopane, ze rozpieprzy system ?
Wg koncepcji kloczka "zaakceptowaniem" pakietu dla instalacji na builderach
mialo byc jago przejscie test -> ready.
 
> 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. 

Tu tez mam watpliwosci.
Nie do konca wierze, ze po

rpm -e pakiet;rpm -i pakiet

dostane *dokaldnie* taki sam stan systemu, jak przed wykonaniem tego.
I nie chodzi mi tu a %files, a o pliki konfiguracyjne, skrypty %pre/%post
i trigery. To czesto jest skopane.

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

A roznice w szybkosci budowania pomiedzy architekturami ?
A gdy zlecenie nie dojdzie na jakis builder na czas z powodu problemow z
poczta ?
A gdy proces budowania jakiegos pakietu sie zapetli (zdarza sie!) na ktorejs
architekturze ?
A gdy proces budowania wymaga niepodzielnych (per chroot) zasobow maszyny,
jak np. pamiec wspolna, czy konkretny port TCP (problem przy wielu
builderach w chroot)?
Nie wszystkie problemy pamietam...

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

Ale moga to byc te krytyczne, wstrzymujace cala reszte.

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

Wlasnie.
A kto te zalozenia powinien wyartykulowac? Cezar? ;_)
Nie widzialem jeszcze kandydatur na RM. A umiejetnosci tych osob sa
baaaardzo wazne.

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