Dnia piątek 27 luty 2009, Mariusz Mazur napisał: > Problem z main jest taki, że to jest ruchomy cel, więc jeśli nawet > poprawisz X, to ktoś może za chwilę popsuć Y. Cały cel snapów jest taki, że > np. tydzień przed wydaniem snapa do main nie wchodzi nic psującego, a po > wydaniu snapa, do snapa wchodzą tylko rzeczy naprawiające (czyli znalezione > nieupgrejdy z wcześniejszej wersji, etc, etc.).
(Odpowiadam na post Mariusza, ale tak na prawdę jest to odpowiedź to postów,
które są odpowiedzią do jego postu...)
Ja widzę sprawę snapshotów trochę inaczej - im mniej przy nich będzie pracy
manualnej i więcej będzie się działo z automatu - tym lepiej. Co powiecie na
takie rozwiązanie:
1. przygotować kilka zestawów pakietów (w sensie ich nazw: kernel, kdebase-
libs, gnome-desktop itd.) w formie list, np.:
- server webowy
- router
- desktop kde
- desktop gnome
2. następnie do th-snapshot-devel wrzucamy to co mamy w th-main
3. automat próbuje zainstalować powyższe zestawy pakietów w chroocie i jeśli
instalacja się nie powiedzie wysyła maila z błędami do RM lub ląduje w logach
na stronie
4. RM lub inne osoby chcące doprowadzić snap-a do stabilności rozwiązują
problemy z logów (dobudowują/przebudowują pakiety itp. itd.)
5. automat po udanej instalacji wrzuca pakiety (które brały udział w
instalacji!) ze snapshot-devel do snapshot.
Pozdrawiam,
--
Rafał Cygnarowski
rafilists [at] gmail [dot] com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
