Wszystko w nowej automatyce też będzie zautomatyzowane (i to znacznie bardziej, niż w ac).
To dobrze :)
Coś mi się nie wydaje. Tutaj jesteś raczej skazany na filtrowanie sobie tego, co chcesz :)
Doh. Przezyje :)
Co do zleceniologów, to się zastanawiałem, czy takowych nie wprowadzić, ale przy samych zleceniach one są właściwie zbędne (chyba). Jeszcze przy odfajkowywaniu paczek do przeniesienia miałyby sens, ale przy samych zleceniach?
Mi tu chodzilo raczej zeby byla lista a'la cvs-commit tylko ze zleceniami (kto, co, kiedy puscil). Buildlogi sa duze, a queue.html nie ma archiwalnych zlecen (wiem, marudze).
Nie ma problemu z implementacją tego, jest raczej problem z tym, jak to miałoby działać. Jeśli się okaże, że jakaś paczka rzeczywiście coś zepsuła, to cofnięcie do starszej w 'main' i tak by nic nie dało, bo wymagałoby ręcznego 'upgrade --downgrade' w poldku. Ciekawym też ile by to zjadało dysku.
Tak. Od tych ktorzy zdazyli dac upgrade wymagalogby to downgrade, ale ci ktorzy jeszcze nie uaktualniali systemu nie nacieliby sie na bubla. Dajmy na to trafia bublowaty kernel do main (w teorii), po dwoch dniach sie dowiadujemy ze cos tam nie dziala poprawnie. Trzeba poprawic, podbic rel, przebudowac i do main. Ale pech chcial, ze ktorys tam builder ma tyly i paczka na nim bedzie za tydzien. Mamy wtedy opcje:
a) puszczamy zlecenie i czekamy tydzien, w tym czasie w main lezy bubel na ktory sie moze naciac wiecej ludzi (nie kazdy czyta listy czy siedzi na irc)
b) przenosimy do main przebudowane paczki oprocz tej dla arch majacej tyly na builderze, grono osob mogacych sie naciac zawezamy do userow jednej arch
c) przenosimy _odrazu_ starsza wersje lezakujaca jeszcze na ftp (czy gdzies), ci co sie juz nacieli - trudno, ale nastepni sie nie natna.
To tylko takie moje rozwazania typu "co by bylo gdyby..."
M.
_______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
