HEAD/STABLE/branch

[Tomasz Kłoczko]

On Mon, 3 Dec 2001, Marcin 'Qrczak' Kowalczyk wrote:

> 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 :-(

Przez cały czas próbuę to przekazać. Owszem teraz jedt dobra pora żeby o
zamknięciu myśleć ale żeby to zamkniecie wykonać trzeba to co jest do
takiego zamknięcia przygotować. Kilka osób wzięło sobie to do głowy i
zaczęło robić końcowe poprawki .. blues, qboosh, filon.

[..]
> 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.

Wbrew pozorom nie jest tego strasznie dużo. Główne ograniczenia są czysto
fizyczne. Każdy może przejrzeć szczególowo kilka rzadziej kilkanaście
pakietów dziennie. co kilka dni takze te dooby które to analizują i
poptawaiją musżą rteż sie oderwać i zajać sie czymś innym (choćby po to
zeby odpocząć czy jeszcze raz spojrzeć an to co przed chwilą zrobiły).  
Obecnie idzie dość sprawnie w tępie około setki tygodniowo. To bardzo
dobre tęmpo. Nie ma senu tego przyśpieszać za mocno. Lepiej wolniej a
dokładniej.

> 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).

Pakietów jest sporo. Powidziałbym bardzo dużo. Przynajmniej mi wydaje się
że lepiej byłoby zacżąć od wysuwanai kandydatór tego co nadaje sie do 
usuniecia. Na bierząco dobrze bezie dostarczać możliwe zestawinia tego co 
juz zrobione i tego co tzreba jeszcze wyczyscić. Tego co można zrobć i 
tego z czym ciężko sobie poradzić.
Jęzlei chcesz sie pobawić w robienie tego o czym mówisz to proszę bardzo. 
faktów nigdy za mało jeżeli tylko ktoś potrafi je wyciagnąc na światło 
dzienne.
Wygenerowane dane prezentujace ajkoś opis tylko powiązań miedzy pakeitami 
i tak jest potrzebny, Przydałoby się żeby takie dane były regenerowane 
zawsze po zmianie zesytawu pakietów. Na ich podstawie można by zapewne
dość do kilku ciekawych wniosków.

> 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.

O tym pisałem juz kilka razy i pisałem takze że jest to warunet sine
quanon całego przedsięwzięcia. Po tym będzie można myśleć o kolejnym
kryterium. Właśnie .. z razcji tego że zasobów jest tak dużo że nie jest w
stanie żaden z nas objąć ich w całości zamaist formułować cały zestaw
kryteriów wydaje mi się że lepiej formułować kryteria cząstkowe, którym
nie koniecznie musża podlegać wszystkie pakiety ale kóre będzie miało
zastosoewanie do konkretnych klas pakietów. Np. wymóg poprawnej pracy w
śrordowisku uzywającym ipv6 lub ipv4, używanie konkretnych bibliotek np.  
żeby term aplikacje używały ncurses, aplikacje operujace na plikach db
używały db3 (możliwie zawężając używanei gdbm czy innych db), żeby
aplikkacje KDE uzywały qt 2.x i kde 2.x (kilkanaście speców które mają
jeszcze jest z czasów kiedy było używane kde 1.x i od tego momentu nie
pojawiły się w nowszej wersji co dzisiaj powoduje że pakiety i spece do
nich można dzisiaj wyrzucić już z repo). Kilka z tych kryteriów które są
możliwe do sformułowanai albo jest od dłuższego czasu wdrażane albo jest
już wrecz w całości wdrożona. Każde z nich ma na celu zawężenie
"horyzontu" do rozmiarów w którym da się już całość objać jakoś jednym
spojrzeniem lub przybliżyć do to możliwie do takiego punktu po to żeby
analiza tego wszystkiego była możliwie prosta/w ogóle prostrza.

> 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.

W druch pierwszych akapitach brak zastrzeżeń z mojej strony. W ostanim
zauważ że nie musimy mieć pełnej zgodności we wszystkich możliwuych
przypadkach.  Wystarczy że mamy pakiet poprawnie budujący się w otoczniue
innych które znajduja sie na ftp. Zagwaranrtowanie tego jest możliwe i
wykonalne. Za resztę przypadków nie możemy brać wprost odpowiedzialności.

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

Temu miały służyć masowe budoania pakietów. Plan w szkielecie jest spójny.
Wymaga tylko realizacji. Opis tego co w skład planu wchodzi był na liście.

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

Hołk.

> 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ę.

Tutaj kluczem może być ten tcl-owy tester oprogramowania. Widzę że kilka 
dni temu pakeit ten wpadł w rawhide czyli inni takzę potencjalnie rokują 
nadzieje czyli że próba pogłębienia tematu może być potencjalnie czymś 
porzytecznym. Niemniej skomletowanie szerszego/akceptowalnego zestawu 
procedur testowania może być dłuższe niż czas jaki chcielibyśmy poświecić 
na zamkniecie 1.0. Ergo: nie należy tego kryterium wiązać wprost z 1.0. 
Owszem nie należy także w żaden sposób powstrzymywać prac w tym kierunku.

> 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ść.

Jeżeli chcesz pzreprowadzić rzeczywiście głębsza analityczną robotę w tej 
kwestii przyjmij jako wyjśćiową listę to co jest na ftp. To jest dość 
dobre przyblizenie na pocżatek. Załóż że to co nowego pojawi się po tym
momencie na ftp (kompletnie nowe pakeity) nie wymaga dodatkowego 
analizowania (można założyć z dużą dozą poprawności takich założeń że to
co wskoczy w najbliższym czasie będzie poprawne apriori czylui że z tej 
analizy bezie mogło być wyłączone).
Po tym kolejno można próbować wykonać kilka iteracji co do tego co usunąć.
Na dalsze kroki w tej chwili nie mam pomysłu ale odnoszę wrażenie że po 
dwuch trzech iteracjach eliminacji zasobów powinno wyglądać to już na 
tyle roząsdnie że nie powinno się na tym dać zawiesić choćby jednego
większego psa .. czyli że będzie to już jednak gotowe do zamkniecia.
Kwestia tylko w tym że trzeba to zrobić i tzreba to wykonać dość
konsekwentnie bez tracenia z oczu całego obrazu co jednocześnie dodatkowo
z racji tego że żadko kto jest w stanie wytrzymać dłuższe pzreciążenie
umysłowe zawęża cały proces do pwiedzmy dwuch tygodni.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*