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

[Tomasz Kłoczko]

On Wed, 11 Dec 2002, Witold Filipczyk wrote:

> > 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.
> 
> Jak będzie pełna automatyka (automatykę wyzwala zmiana Release speca),
> to rewizja speca a także rewizje wszystkich źródełek zostaną
> zapisane w pliku, który zostanie ustawiony w kolejce oczekujących.

Wyzwalanie bbudowanai zajmuje relatywnie malutki ułamek czasu w stosunku
do późniejszej obróbki wyników.

> Żeby nie przeszkadzały w działaniu mechanizmu pakiety, których się nie buduje
> na danej architekturze powinny być tagowane, np.
> blablabla.spec z tagiem NON_SPARC nie będzie w ogóle puszczany na builder
> SPARCowy.

Wystarczy tradycyjni w %setup wstrzelić makro %dump i sparwdzić na jakich 
architektórach sie coś może budować.
Dokąłdanie etykeit do arch jest tu niepotrzebnym powielaniem informacji 
jakie zawierają już spece. W przypadku tylko stwierdzenai że pakeit nie 
mzoe być pzrebudowany na danej arch wystarczy nie odsyłać nigdzie wyników 
obróbki zlecenia.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*