nest
wrobell
wrobell w ite.pl
Czw, 6 Lis 2003, 01:19:11 CET
On Wed, Nov 05, 2003 at 10:23:41AM +0100, Witold Filipczyk wrote:
> Nest to ma być poligon doświadczalny. Proponuję doświadczenie polegające
> na całkowitym zautomatyzowaniu procesu budowania. Tak żeby budowanie
> pakietów i udostępnianie ich na FTP było całkowicie bezobsługowe.
>
> Budowanie polegałoby na tym, że za każdym razem
> instalowane są potrzebne do zbudowania pakiety, budowanie odbywa się
> w chroocie. Po zbudowaniu wszystko co zostało zainstalowane jest kasowane.
> Zbudowane pakiety przenoszone są na FTP. Raz na dzień a może i częściej
> regenerowane są indeksy dla poldka.
> Powinna być zachowana możliwość ręcznego puszczania zleceń z najwyższym
> priorytetem.
> Ze średnim priorytetem pakiety budowane z CVSu (automatycznie po podbiciu
> release lub numeru wersji).
> Z najniższym priorytetem przebudowywane by były pakiety na skutek zmiany
> wersji biblioteki od której są zależne.
> Realizacja ostatniego warunku nie jest trywialna, ale jest to możliwe
> do zrobienia.
>
> Developerzy mogli by się zająć "developerstwem" zamiast tracić czas
> na puszczanie zleceń, instalowanie pakietów na builderach, itp.
> Więcej braków zależności zostałoby wyłapanych i "czas reakcji" - czas
> od pojawienia się nowej wersji do pojawienia się zbudowanego pakietu
> byłby krótszy. Proces budowania można dowolnie zrównoleglać.
>
> Czas budowania byłby dłuższy o czas instalacji pakietów, ale ta instalacja
> nie trwa długo.
widzę, że ty znowu swoje... :-)
1. nie zdajesz sobie obecnie jak wygląda obecnie budowanie pakietów z tego
co piszesz...
2. większość z tego co napisałeś jest obecnie robione. wyjątek - automatyczne
budowanie po zmianie w cvs-ie. i wątpię by był to dobry pomysł. przykład
choćby z wczoraj - postgresql.spec. spec został zmergowany na head z devel
(zmiana wersji). akurat miałem chwilkę. ale dopiero wieczorem miałem
dodatkowy czas na to by spojrzeć na spec-a i zweryfikować zmiany oraz
przetestować _dokładnie_ pakiety (dodam jeszcze, że pakiet był weryfikowany
przez jarka przed moim merge'em). i dopiero teraz może postgresql pójść
na buildery. nie wcześniej. fakt, czasami pakiet zaraz po podbiciu
wersji jest puszczany od razu na buildery, ale bardzo często warto
poczekać chwilę po commicie w cvs-ie, ponieważ wykonane zmiany są
weryfikowane przez inne osoby, które interesują się daną działką. dlatego,
_nie_warto_ automatycznie puszczać pakietu do zbudowania, ponieważ zbyt
często się mylimy i są wymagane dalsze poprawki. już nie wspomnę o tym,
że taka automatyzacja wymaga od developerów więcej dyscypliny: najpierw
trzeba commitować patch-e, a dopiero później spec-a, żeby pakiet mógł się
zbudować
wrobell <wrobell w ite.pl>
-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 189 bytes
Desc: nie znany
Url : /mailman/pipermail/pld-devel-pl/attachments/20040626/38cd311d/attachment.bin
Więcej informacji o liście dyskusyjnej pld-devel-pl