ra-general-updates: kto, z kim, kiedy ?

[Andrzej Krzysztofowicz]

> On Wed, Dec 11, 2002 at 12:30:08PM +0100, Andrzej Krzysztofowicz wrote:
> > > On Tue, 10 Dec 2002, Marcin Bohosiewicz wrote:
> > > [..
> > > > Dla ix86 (i386,i586,i686) i ppc buildery sa i sie kurza.
> > > > Alpha chyba w CS tez juz stoi gotowa do uzytku.
> > [...]
> > > Tak czy inczje IMHO do obecnech buildera wartoby dorobić nasepujące 
> > > funcje:
> > > - cancel zlecenia które czy to jest jesszcze w klejce czy to wąłsnie jest 
> > >   w trakcie realizacji,
> > > - zlecenie z priorytetem - np. po to żeby nawet ptrodukcyjne buuldery 
> > >   wykorzystywax cdo tego zeby mogłgły uczestniczyć w testowym w kółko 
> > >   wykonywanym budowaniu pakietów .. tego typu zlecenia powinny iść z 
> > >   niskim priorytetem ale zlecenie "produkcyjne" powinno wejść jako 
> > >   pierwsze po najbliższym skończeniu budowania pakietu,
> > [...]
> > > Komuś przychodzi jeszcze coś do głowy ?
> > Tak.
> > 1. Sugestia, zeby wszystkie zlecenia produkcyjne dla builderow wymagaly
> >    podawania taga, na podstawie ktorego nastapi przebudowanie. Nie powinno
> >    to sie budowac po prostu z head, jak dotychczas.
> Byłbym za tym, żeby budować wszystko z HEAD, a po przebudowaniu tagować.
> Większość speców powinna się dać zbudować na wszystkich wersjach
> PLD i architekturach.

Budowanie dla roznych architektur zazwyczaj nie jest jednoczesne. A ktos
moze (i czasami robi) commity *po* wyslaniu zlecenia (nie ma zadnej
publicznie dostepnej informacji, ze cos wlasnie czeka na przebudowanie i
nalezy sie z commitami wstrzymac), co w efekcie czesto daje pakiety
zbudowane na podstawie roznych wersji speca / zrodel.

Chyba, ze jakies locki dla cvs-u ustawiane przez buildery wymyslimy...
Mysle, ze lepiej zdejmowac tagi, jesli pakiet sie nie zbuduje. I to nawet
moze sie odbywac automatycznie na podstawie wynikow z builderow.

> Duża łatwiej jest działać na HEAD niż z każdym pakietem się bawić
> w jakieś tagi.

Co za roznica, jesli taguje automat w chwili wysylania zlecenia ?

> > 2. Priorytety. Warto miec ich wiecej niz 2. Na przyklad w takiej sutuacji:
> >    - puszczamy do "produkcyjnego" przebudowania 50 pakietow,
> >    - na jednym z pierwszych okazuje sie, ze do jego zbudowania trzeba
> >      zainstalowac na builderze jakis pakiet X, ktory nie zostal jeszcze
> >      przebudowany,
> >    - zeby nie czekac pol dnia - puszczamy pakiet X z wyzszym priorytetem
> > 
> > > A jeszcze jedno. W przypadku builderów z obsługą kilku arch odbieranie
> 
> Może dwie kolejki: superusera i automatyczna.
> Nawet w kernelu jest tylko tryb jądra i użytownika.
> Pakiet, na którym builder się wyłoży - na koniec kolejki.
> To co proponował Marcin Chojnowski na devel-en, żeby dla każdego budowanego
> pakietu od nowa tworzyć środowisko budowania, ściągając poldkiem tylko
> pakiety z BR.
> Jeśli maszyna ma dużo RAMu, można zrobić chroot-a na ramdysku i nie będzie
> opóźnień.
> Przebudowane pakiety trafiają do test.
> A do buildera są ściągane z głównego ftp-a.
> Jeśli na test jest świeższy pakiet niż na ftp-ie, to włącza się alarm,
> maszyna zatrzymuje się i czeka na decyzję operatora.

Czyli raczej trzy: mial byc jeszcze priorytet niski - dla pakietow
nieprodukcyjnych.

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