Buildery

[Witold Filipczyk]

On Tue, Jan 14, 2003 at 11:29:38AM +0100, Andrzej Krzysztofowicz wrote:
> > 
> > Stacja bezdyskowa - chodziło o nowe komputery, dedykowane do budowania.
> > Nie warto kupować dysku, lepiej zainwestować w RAM.
> > Po zbootowaniu system będzie chodził nonstop.  Bezdyskowość nie jest tu istotna.
> 
> A co z OpenOffice ?
> Zmalaly wymagania do jego przebudowy, czy skadis wykombinujesz 6+ GB
> ramdysku ???

To jest wyjątek, potwierdzający regułę.
Trzeba być utalentowanym, żeby napisać taki program.

> > Wszystkie devele i inne pakiety potrzebne do zbudowania powinny być brane
> > oczywiście z tego samego źródła.
> > Napisałem skrypt poldekbuild, który instaluje potrzebne pakiety i uruchamia
> > rpmbuilda.
> > Instalacja wszystkiego od nowa, zapewni to, że pakiety będą budowane zawsze
> > w tym samym środowisku.  Nie będzie sytuacji, że zwykły user nie da rady
> > przebudować pakietu, bo czegoś nie miał zainstalowanego a na builderach
> > było.
> > Dlatego ramdysk tutaj przyspieszyłby trochę. 
> 
> IMO, ramdysk ma duze szanse byc przyczyna zmniejszenia stabilnosci systemu.
> Juz nie raz sie zdarzaly rozne OOM podczas budowania: czy to spowodowane
> bledami kompilatora, czy czyms innym...

To nie jest winą ramdysku, a błędów w systemie, które i tak trzeba poprawić.

> > > Apropos strony głównej, to jakbyś słuchał kłoczka to też wiedziałbyś, że 
> > > nie ma możliwości umieszczenia tam linków.
> > 
> > Nie pamiętam co kloczek mówił.  Możliwości są, kwestia koncepcji.
> 
> Czasem nie jest to problem natury prawnej... ?

W Polsce ludzi prawem straszysz?

> > developer robi commita.  Jeśli w specu zmienił się Release lub Version lub
> > jeszcze coś innego, np. w pakietach z Release poniżej 1, mamy request
> > dla buildera.
> 
> Np. ktos zrobil najpierw commit speca, a potem powrzucal zrodla... Czesto
> sie zdarza. ;)

Następnym razem zrobi "in the right way".  src.rpm się nie zbuduje,
nie ma problemu.

> > Będzie też kolejka SRPMS do przebudowania i RPMów do podpisania.
> > Na każdej kolejce będzie operował w nieskończonej pętli jakiś skrypt.
> > Będzie brał pierwszy (najstarszy) element z kolejki, przetwarzał
> > go i zapisywał wyniki w innych kolejkach (katalogach).
> > Jeśli kolejka jest pusta proces zasypia na określony czas.
> 
> Np. potrzebne jest przebudowanie glibc z powodu jakiegos problemu security.
> A w kolejce jest na poczatku OO i mamy 24h z glowy. Zreszta zupelnie
> bezsensownie, bo i tak za chwile trzeba to bedzie puscic jeszcze raz.

Na OpenOffice nie starczy pamięci ;-)
Zawsze można przesunąć pakiet na początek kolejki (ręczna interwencja
lub automatycznie).  Builderów będzie dużo, kolejki będą krótkie (kapitalizm).

> Bezmyslna automatyzacja niekoniecznie jest dobrym pomyslem.
> 
> > NFS zapewnia prostotę. Przy połączeniach 1Mbit/s i szybszych nie powinno
> > być dużych opóźnień.
> 
> Sprawdzales co sie dzieje, gdy sie pojawia duze straty na takim polaczeniu?

Nie.
Pisałem, że jestem za lokalnymi builderami.
Zainstalowanie pakietów, skopiowanie wyników, to nie będzie mocno obciążało.

> > Jeśli zostanie osiągnięta "masa krytyczna" builderów, to developerzy nie
> > nadążą z produkcją speców.
> 
> Wiele tej masy nie potrzeba. Buildery Ra byly rzadko zapchane...

No tak, ale nie wszystkie pakiety zostały przebudowane.

-- 
Witold Filipczyk
<witekfl w poczta.onet.pl>