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

[Jakub Bogusz]

On Wed, Dec 11, 2002 at 06:06:53PM +0100, 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.

To jest niebezpieczne.
Nawet jeżeli założyć pełne zaufanie do osób mających r/w do CVS - to
hasła lecą praktycznie nieszyfrowane (w tej samej postaci, co w .cvspass
- jakaś stała mapa).

Chociaż... teraz też nie jest najlepiej - wystarczy trafić w odpowiedni
moment i zmodyfikować coś już po puszczeniu zlecenia :/
Puszczanie przebudowy z tagiem jest potrzebne, ale taga też można
przenieść... czy w naszym cvs są jakieś restrykcje dotyczące tagowania?
Czy tagowanie jest logowane?

BTW, nie wiem czy tak jest na builderach, ale użytkownicy, z których
prawami są budowane pakiety, powinni mieć uidy inne niż wszyscy
użytkownicy w systemie i innych chrootach (zwłaszcza systemowy użytkownik
builder, mający dostęp do sudo chroot, co daje roota).

> > Czyli raczej trzy: mial byc jeszcze priorytet niski - dla pakietow
> > nieprodukcyjnych.
> 
> To wymaga dużej "lookup-table" ze spisanymi priorytetami
> dla poszczególnych pakietów.
> 
> Obciążenie builderów nie będzie zbyt duże, szczególnie że ma być
> ich kilka(naście).

Obciążenie nie jest duże, bo w jednym chroocie budowany jest jeden
pakiet naraz (żeby było inaczej, trzeba by mieć zabezpieczenie przed
konfliktami par pakietów, o których pisałem).
Za to kolejka będzie dłuuuga (na x86 to jeszcze, ale gcc 3.2 na alphie
wlecze się nieznośnie...).

"Rozproszony system builderów" może służyć testowym przebudowom -
pakiety do użytku mogą być budowane tylko na najbardziej zaufanych
maszynkach.


-- 
Jakub Bogusz    http://www.cs.net.pl/~qboosh/