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