Status AC i TH

[Rafał Cygnarowski]

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

-------------- następna część ---------
Załącznik, który nie był tekstem został usunięty...
Name: nie znany
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : /mailman/pipermail/pld-devel-pl/attachments/20090227/ec7794e5/attachment.sig