Status AC i TH

[Mariusz Mazur]

Dnia czwartek, 26 lutego 2009, Paweł Zuzelski napisał:
> Nie wiem czy Cię dobrze zrozumiałem, proponujesz, żeby struktura katalogów
> wyglądała tak:

Dokładna struktura katalogów jest drugorzędna, kwestia nazwania th-test 
experimentalem, a th-ready testingiem (czy jak to się tam w debianie 
dokładnie zwie). Czyli czy pld, czy debian, pakiety idą 
experimental->testing->main, po czym w pewnym momencie main jest mrożone i 
wydawane jako cośtam, a reszta świata idzie do przodu (ino my byśmy to robili 
bardziej w przedziałach czasowych kernelowych, czy tam ubuntowych, niż 
debianowych).

> To wynika z samej natury projektu. Ale poszczególne drobne wydania kernela
> (powiedzmy przejście z 2.6.28.6 -> 2.6.28.7) są moim zdaniem bardzo dobrą
> analogią pojedyńczego upgrade'u th (tzn przeniesienia pakietów z ready ->
> main).

Niezbyt. 2.6.28.6 -> 2.6.28.7 zawiera kilka bugfixów (czy wręcz jeden). Drobny 
upgrade th może mi podmienić pythona 2.5 na 2.6.

> Pytanie czy ktokolwiek by używał takich snapshotów. Snapshoty tak jak je
> proponujesz osiąŋałeyby EOL w chwili wydania. A to oznacza, że raz na jakiś
> czas uzytkownik będzie musiał robić "duży" upgrade.

Główną funkcjonalnością snapshotów byłoby trzymanie czegoś, co wiemy, że się 
instaluje i działa (bo miałoby kilka kryteriów wydań). Więc wiem, że na 
vserwery sobie mogę th head instalować, najwyżej poprawię coś i zupgrejduję, 
ale już na główny system daję ostatni snapshot, bo obsługa vserwerów bez 
known bugów to jedno z kryteriów wydań (co jest akurat bardzo PLD-owym use 
casem; ja mam na dwóch systemach ac na głównym, bo akurat obsługa vserwerów w 
th była w danym momencie skopana i nie miałem jak zainstalować).

> Co powinniśmy zrobić, żeby nie skończyło się na marzeniach?

Nie wiem. Na pewno bez przemiału infrastruktury by się nie obyło, żeby np. 
było dla wszystkich deweloperów oczywiste jak zrobić prosty fix do ostatniego 
snapshota i go puścić na snapshotowe buildery i żeby nie wymagało to 
uprzedniego dopytywania się kto może nadać uprawnienia, gdzie cośtam słać, 
czy coś. I żeby dało się zrobić tryb -rc przez tydzień, że wchodzą tylko 
bugfixy. Trzeba by to modelować jakoś na architekturze i metodach współpracy 
kernelowo-gitowych. W szczegółach -- serio nie wiem jak, nie zastanawiałem 
się. Zmiany musiały by być raczej spore. Linus miał wizję, zaimplementował, 
pokazał światu i świat później zaczął budować wokół tego. Inaczej (czyli 
robić to przez komitet) raczej sobie nie wyobrażam. 

Jest to imho w pewien sposób najlżejszy sposób na robienie rzeczywistych 
releasów, acz czy rzeczywiście byłoby to wystarczająco użyteczne, żeby się 
ludzie tym interesowali i, co ważniejsze, deweloperzy tego używali -- nie 
wiem. Acz jeśli z całej zabawy by się tylko ostała bardziej giętka i 
wydajniej działająca infrastruktura, to pewnie by się nikt nie obraził :)

(Marzenia są fajne. Snapshoty do których wchodzą tylko niepsujące bugfixy, po 
wydaniu takiego snapshota ludzie zaczynają próbować upgrejdować z 
poprzedniego, więc dochodzą też poprawki na upgrejdy i różne triki, żeby 
płynniej szło (to by lądowało opisane w zawsze tym samym miejscu na wuwie; 
razem z listą większych zmian, typu pythony, mysqle, cokolwiek). Tiaa, 
marzenia są fajne :)


-- 
Oceniaj innych po zamiarach, a siebie po wynikach.
                                                                 Guy Kawasaki
Wykształcenie jest rzeczą godną podziwu, acz dobrze czasem
pamiętać, że niczego, co warto wiedzieć, nie da się kogoś nauczyć.
                                                                  Oscar Wilde