HEAD/STABLE/branch

[Marcin 'Qrczak' Kowalczyk]

Mon, 3 Dec 2001 18:32:43 +0100 (CET), Tomasz Kłoczko <kloczek w rudy.mif.pg.gda.pl> pisze:

>> Dla mnie to jest nienaturalne. HEAD powinien być wersją rozwojową,
>> branche powinny być dla poszczególnych wersji stabilnych.
> 
> Powtórże jeszcze raz i tym razem już ostani dlaczego teraz tego nie możemy 
> zrealizować. Poprostu z obecnych zmian które są powyzej STABLE bardzo dużo 
> powinno wejść do 1.0. Gdyby teraz zrobić rozdzielenie to spowodowałoby to 
> koniecznosć wykonywania dwyrotnie zmian na HEAD i w branchu.

Innymi słowy, nie jesteśmy jeszcze przygotowani do wypuszczenia PLD 1.0
w najbliższym czasie :-(

Model etykietowania, o którym mówię, zakłada, że etykieta wersji
stabilnej jest nakładana wtedy, kiedy pozostało w niej niewiele zmian -
i równocześnie wtedy, kiedy pojawiają się już zmiany przeznaczone do
wersji przyszłych, których nie chcemy w najbliższej stabilnej, bo są
ryzykowne. Model nie robi cudów i nie zmniejsza potrzebnych zmian
w pakietach.

U nas taki moment nie istnieje: jeszcze dużo zmian czeka wersję stabilną,
a już musimy wstrzymywać nowości (jądro 2.4, gcc 3, qt 3). To chyba wynika
z dużej masy wszystkiego: zanim uporządkuje się w jednym miejscu, inne
miejsce ostro idzie do przodu, i nigdy nie jesteśmy wszędzie na czasie.



Wydaje mi się, że pomógłby jakiś mechanizm w miarę szybkiego oceniania
stabilności po poszczególnych zmianach. To znaczy: W każdej chwili
istnieje bieżący zbiór pakietów tworzących kandydata na wersję
stabilną. Na początku zawiera on minimum, np. rpm i domknięcie według
zależności Requires i BuildRequires (może istnieje już gdzieś jakaś
lista bazowa).

Ważne, żeby od samego początku zbiór ten spełniał niezmiennik: każdy
pakiet daje się w środowisku tego systemu przekompilować i działa.

W tej chwili większość pakietów ma większe problemy z budowaniem
się niż z działaniem. Mój domowy system jest dość podobny do PLD
i nowy pakiet w 1/3 przypadków ma kłopoty z kompilacją, ale po udanej
kompilacji w 90% działa.

Kryterium dodania nowego pakietu do kandydata na wersję stabilną jest
jedno: zachowuje niezmiennik. Czyli sam jest dobry i nie destabilizuje
reszty. Takie samo kryterium dotyczy wprowadzenia zmiany, np. wymiany
na nowszy.

Widzę dwa problemy z rozstrzyganiem, czy niezmiennik zachodzi. Po
pierwsze są różne konfiguracje i pakiet może się kompilować w jednych
warunkach, a nie kompilować w innych. Po drugie ocena, czy pakiet
działa, wymaga człowieka.

Pierwszy problem można próbować obejść w taki sposób, że niezmiennik
jest bez przerwy weryfikowany przy zmieniających się konfiguracjach.

Dla uproszczenia można przyjąć, że kiedy nowy pakiet się jakkolwiek
zbuduje i działa, to jest już uznawany za dobry. Jeśli jednak
po zmianie konfiguracji się zepsuje, to jego stan jest zmieniany
na niepewny (choć nie wiadomo, czy akurat on zawinił), są o tym
informowani ludzie i należy czym prędzej zdiagnozować problem
i przywrócić niezmiennik.  W tym czasie jest stan alarmowy, który
musi być postrzegany jako bieżący problem do szybkiego rozwiązania.

System sprawdzi się wtedy, kiedy w sytuacji braku zmian listy pakietów
niezmiennik sam z siebie się nie psuje mimo wielokrotnych rekompilacji
i reinstalacji.

Drugi problem powinno rozwiązać się pisząc minimalne nieinteraktywne
testy, które próbują przede wszystkim odpalić główną binarkę pakietu.
Pakiet bez testu jest automatycznie sprawdzany tylko pod kątem
budowania się.

Przy zachowaniu niezmiennika można ostrożnie dodawać kolejne pakiety
do kandydata i może kiedyś zrobi się z tego wersja stabilna.

Główną myślą pomysłu jest to, żeby nie rozpoczynać od pełnej listy
pakietów i próbować nadawać jej stabilność, tylko rozpocząć od
stabilnej listy pakietów i stopniowo nadawać jej pełność.

-- 
 __("<  Marcin Kowalczyk * qrczak w knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^
QRCZAK