buildery: koncepcje i pewne pytania

[Witold Filipczyk]

On Fri, Nov 30, 2001 at 02:48:38PM +0100, Tomasz Kłoczko wrote:
[...]
Można jeśli jest miejsce na dyskach zbierać wszelkie informacje,
aczkolwiek z jakimikolwiek wnioskami na ich podstawie lepiej
się wstrzymać.  Różne badane cechy nie są od siebie niezależne,
więc należałoby sprawdzać najpierw zmieniając tylko jedną właściwość,
potem po dwie, itd., ale to by trochę trwało i było by nudne.

Najważniejsze pytanie jakie flagi dla kompilatorów powinny być defaultowe,
tzn. -O2 czy -O3, a może -O4(?) i inne opcje.  Będzie to można sprawdzić
przynajmniej na kompilatorach.


> Co jest potrzebne do tego żeby powyższe zrealizować ?
> 
> Po pierwsze trzeba określić jakie konkretnie dane trzeba zbierać i jaką 
> metodą. Jeżeli to mają być wyniki z time to ponieważ jest tu kilka rzecy 
> potencjalnie do usyskania to tzrebaby okreslić jak potrzbne dane mamy 
> zbierać ? Mówiąc inaczje trzeba określić metodę pomiaru. Druga sprawa to 
> metoda obróbki tych danych.
> Mam tu niemniej osobiście tylko mgliste pojęcie o tym jakie dane zbierać i 
> jak je obrabiać. Jęzli ktoś miałby tu jakieś konkretne pomysły jak to 
> rozwiazać to prosze o zgłaszanie takich propozycji.

Zbierać maksymalnie dużo informacji, tyle na ile starczy miejsca.
(Od przybytku głowa nie boli).
Proponuję odpalić 'top' z odpowiednimi opcjami w szczególności opcją
b i wyniki dopisywać do jakiegoś pliku.
Z tych plików każdy będzie mógł sobie wyciągnąć to co będzie chciał.
 
> 
> Założenia co do pracy builderów przebudowyaania pakietów w kółko są mnei 
> wiecej takie:
> - jest maszynka zajmujaca się rozdzielaniem pakietów miezy resztę maszynek 
>   i na której są zbierane i obrabiane wyniki takich budowań,
> - każdy będzie mógł zgłosić swoja maszynke do pzrebudowywanai pakietów,
> - builder przy okazji budowania bezie mógł zwrócić dodatkowe dane 
>   dotyczące obciązenai i czasu kompilacji pakietu,
> - dane o builderach zgłasznych są niejawne i upublicznieniu podlegać bendą 
>   tylko dane sumaryczne z budowań (ilość jednostek, ilość jednostek 
>   konkretnego typu, czas pzrebudowanai całosci i inne dane które da sie z 
>   tego wyciagnąć). Jeżeli ktoś by chciał żeby dane dotycżace tego że 
>   urzyczył jakąś jednostkę na budowanie były publicznie dosepne ("kto nas 
>   wspiera ?") to nie widże żeby też to prezentować.
> - zapewnić trzeba powtarzalnosć środowisk budownych pakietów.

Wydaję mnie się, że sensownym rozwiązaniem byłoby gdyby wszystkie buildery
miały wspólny system plików po NFSie read-only, a jeśli sieć jest za wolna
to używane pliki zsynchronizowane z tym co w repo czy gdzieś tam.
Odbiór wyników w jednym (kilku) katalogach (rw) lub przez jakąś bramkę. 

Do tego kilka demonów po stronie builderów, każdy w oparciu o 'make', tzn.
make odpalany w równych odstępach czasu.
Jeśli jakiś plik się pojawi w katalogu to go obrobić i wynik przerzucić do
innego katalogu, w którym działa inny make z innym Makefile-m.
W końcu w jednym katalogu wysyłka danych na komputerek zbiorczy.


Przy okazji powtórzę jeszcze, że potrzebna jest też automatyka przy FTP,
tzn. dla każdego nowego pakietu:

rpm -U pakiet --justdb

i coś jeszcze.  Jeśli pakiet się nie "doinstaluje" to jakieś info z opisem
błędu też powinno gdzieś pójść.


Gdzie jest skrypt robiący .iso ?

WF