Co by tu zmienic w PLD...

[Marcin Krol]

Hello.

Od dłuższego już czasu zastanawiałem się co by tu jeszcze można zmienić
w PLD (na lepsze oczywiście). Na przeszkodzie jednak zawsze stał brak
czasu. Wiem, że takich zmian chcieliby niektórzy użytkownicy, może więc
i wśród developerów znajdą się chętni? Jeżeli MY czyli PLD jako zespół
ludzi tworzących tę dystrybucję będzie chciało wprowadzić te zmiany w
oficjalnej wersji - super. Jeżeli jednak pomysł spotka się ze sprzeciwem
i oficjalne PLD pozostanie tym czym jest teraz to zmiany te będę chciał
wprowadzić w Titanium. Bez owijania w bawełnę - szukam deweloperów,
którzy by pomogli zrealizować, a później utrzymywać taką... eee... inną
wersję PLD niezależnie czy to będzie oficjalnie czy jako Titanium.

Wybaczcie być może przypadkową kolejność i zapewne braki lub nie do
końca wyjaśnione kwestie w poniższym tekście, ale po prostu będę
spisywał moje luźne opinie i pomysły w miarę przypominania ich sobie, a
resztę załatwi ew. dyskusja w wątku... chyba że zostanie on olany :)



Oficjalne PLD czyli Th działa chyba obecnie wg zasady "podbić wersję,
podbić wersję, podbić wersję, o cholera, przestało działać... trudno...
podbić wersję, podbić wersję itd". Przynajmniej ja odnoszę takie
wrażenie od jakiegoś już czasu.

Krótko mówiąc główną ideą istnienia Th stała się pogoń za numerkami co z
kolei powoduje bardzo częste przypadki nie działania czegoś. Bynajmniej
nie jest to tylko moja opinia, ale również wielu osób, które znam i
które z własnej woli (żadnej z nich nie namawiałem) przesiadły się na
Titanium dlatego, że taka gonitwa im z różnych względów nie odpowiada.
Dla tych osób Th jest systemem, który nie nadaje się na produkcję.

Nie mam nic przeciw podbijaniu wersji, ale zdecydowanie nie powinno to
wpływać na działanie i stabilność systemu. Rozwiązaniem może być
prowadzenie równolegle dwóch wersji PLD - nazwijmy je narazie stabilną i
rozwojową.

Wersja stabilna to mniej więcej obecne Titanium, wersja rozwojowa to
mniej więcej obecne Th. "Mniej więcej" dlatego że widział bym
następujące zmiany:

1. Dla każdej wersji stabilnej ustalamy wersje pakietów typu glibc, gcc,
kde, gnome itp. Po osiągnieciu tych założeń wersja staje się snapshotem
(o snapshotach trochę więcej w dalszej części)

2. Do takiego snapshota trafiają później jedynie aktualizacje nie
zmieniające ustaleń z pkt 1, zapewniające ciągłość i poprawność
działania. Priorytetem jest niezawodność i bezpieczeństwo, a nie numerki
wersji.

3. Zaraz po stworzeniu snapshota staje się on również wersją rozwojową -
bazą dla kolejnego snapshota. Na tym etapie lądują tam np nowsze gcc,
nowy postgresql czy inne "grube" zmiany. Ta wersja nie musi działać
stabilnie w początkowym okresie istnienia, dopuszczalne są wszelkie
zmiany o ile nie stoją w sprzeczności z założeniami przyjętymi dla
danego snapshota. Rozwój skupia się na dążeniu do owych założeń i
eliminacji niespełnionych zależności itp.



Snapshot - kopia całego drzewa FTP wykonana w momencie osiągnięcia
przyjętych założeń. Nazywać je można np podobnie jak Gentoo czyli rok
wydania + nr wydania w danym roku - 2010.01, 2010.02 itd. Utrzymywany
jest zawsze tylko jeden snapshot. Jeżeli zasoby dyskowe pozwolą
przetrzymywany jest jeden archiwalny snapshot, w którym nie następują
już żadne zmiany i aktualizacje. Do tego wersja rozwojowa. Na przykład
wyglądało by to tak:

Na FTP są nasętpujące katalogi:

/2010.01 - archiwalny snapshot
/2010.02 - aktualny snapshopt
/devel - wersja rozwojowa

W chwili osiągnięcia przez wersję rozwojową założeń robi się:

rm -rf 2010.01
cp -R devel 2010.03

Zawartość snapsota to byłoby niemal standardowe:

/2010.01/archive
/2010.01/PLD
/2010.01/test

Gdzie PLD to to samo co obecnie czyli główne drzewo pakietów. Do test
lecą paczki wypychane przez buildery. Ponieważ w założeniu aktualizacje
nie będą duże (security, minor version) możemy chyba odpuścić sobie
drzewko ready. archive z kolei będzie zawierał po 1 starszej wersji
wszystkich pakietów, które są przenoszone z test do PLD.

Mam nadzieję, że wyjaśnia to ogólnie zarys mojego pomysłu :)

Na podobnej zasadzie działa obecnie Titanium i jak dla mnie ta metoda
się sprawdza. Obecnie wygląda to tak:

1. Do Th leci sobie ileśtam nowych wersji różnych i różniastych paczek.
2. Z nich wybieram to co chcę mieć w kolejnej porcji aktualizacji Titanium.
3. Ślę zlecenia na buildery, pakiety trafiają do test.
4. Rozwiązuję większość problemów z zależnościami.
5. Wykonuję upgrade swoich maszyn testowych.
6. Jeżeli coś nie działa lub upgrade się sypie - poprawiam.
7. Jeżeli wszystko działa paczki lecą do ready.
8. Rozwiązuje ostanie (zazwyczaj te najgorsze) problemy z zależnościami.
9. Całe ready ląduję w PLD (main).
10. Starsze wersje pakietów z PLD (main) lądują w archive co umożliwia
łatwy downgrade jeżeli coś niedziałającego się jednak prześlizgnęło.
11. W tym czasie wykonał się punkt nr 1, a ja robię goto 2.

Nie będę ukrywał, że powyższy zestaw czynności powinien być wykonywany
częściej niż robię to obecnie, ale sam po prostu nie wyrabiam :/



Niezbędne bedą dwie kopie builderów - jedne dla aktualnego snapshota,
jedne dla wersji devel. De fakto nie potrzebujemy tu nowych sprzętów. Są
już buildery Titanium i Th. Podobnie jest z FTP. Obecnie mamy dwie
wersje systemu. Co najwyżej doszła by trzecia, archiwalna o której
wspominałem powyżej, ale nie jest to wymóg konieczny. Zamiast
archiwalnego snapshota można by oprócz devel zrobić wersję experimental,
gdzie mogłoby panować totalne gonienie za numerkami i wszelkiego rodzaju
zmiany byłyby dozwolone, a nawet wskazane. Nic z wersji experimental nie
trafiało by bezpośrednio ani do devel ani do snapshotów. Był by to po
prostu totalny poligon do testowania co i dlaczego się wywali oraz
przygotowywania nowych rzeczy dla wersji devel - przykładowo gcc ileśtam
beta. Wymagało by to co prawda trzeciego zestawu builderów, ale może
warto...



Jak to zacząć? Przez połączenie Titanium i Th. Mogło by to wyglądać np tak:

1. Wybieramy ujednolicenie architektury między Titanium i Th (486 vs
586) albo po prostu z nich rezygnujemy i zostajemy przy i686 i x86_64.

2. Repo main z Titanium ląduje na FTP jako pierwszy snapshot. Titanium
jako takie jest usuwane.

3. Repo main Th ląduje na FTP jako wersja devel. Th jako takie jest usuwane.

4. Część rzeczy z Th bym odpuścił... ogólnie biorąc, te problemotwórcze
jak również niektóre bety czy RC. Konkretnych paczek nie mam w tej
chwili na myśli. Trzeba by po prostu wspólnymi siłami ustalić co nie
działa obecnie w Th prawidłowo lub powoduje problemy i narazie z tych
wersji zrezygnować.

5. Ustalić komplet wersji - nazwijmy to - "core" pakietów i nie puszczać
nic nowszego tylko wyeliminować wszelkie problemy w zależnościach i
funkcjonowaniu pakietów / systemu.

6. Th będące już develem snapshota staje się kolejnym snapshotem.
Titanium czyli poprzedni snapshot wylatuje. Dalej działamy wg tego co
pisałem powyżej.

7. Do devela mogą powrócić rzeczy, z których zrezygnowaliśmy w pkt. 4.
Dalej sprawy się już toczą po nowemu.



Po co to wszystko? Łączymy cechy Th i Titanium cenione przez
użytkowników obydwu tych linii. Ci co cenią stabilność i niezawodoność
ponad numerki wersji używają snapshota. Ci co wolą nowszy, ale nadal
działający system używają sobie wersji devel. Ci co chcą testować glibc
2.14 alpha 5 kompilowane z gcc 4.6 pre-alpha używają wersji experimental
jeżeli byśmy się na taką zdecydowali. Dodatkowo system działający na
powyższych zasadach ma moim skromnym zdaniem większe szanse zaistnienia
"na rynku". Nie żeby mi na tym specjalnie zależało. Ot taka moja opinia
jest i tyle.



Odwieczną bolączką PLD jest brak siły roboczej w ilości wystarczającej
do zapewnienia wyższej jakości naszej dystrybucji. Zakładając, że rąk do
pracy jakoś specjalnie nie będzie przybywać, oraz że może ich wręcz
ubywać (rodzina, praca, lenistwo czy też inne rzeczy przychodzące z
wiekiem) trzeba zadać sobie pytanie - czy to o czym pisałem powyżej jest
w ogóle realne? Moim zdaniem są szanse. Sprawę widzę następująco:

1. Jeżeli nic się w PLD nie zmieni to pewnego pięknego dnia nasza
dystrybucja po prostu przestanie istnieć. Tak Titanium jak i Th.

2. Idąc tym tokiem myślenia nie ryzykujemy nic wprowadzając zmiany.
Jeżeli nie wyjdzie - skutek będzie taki sam jak przy ich braku. Co
najwyżej koniec nastąpi wcześniej.

3. Pewna grupa deweloperów jest w miarę aktywna od dłuższego już czasu i
można założyć, że te osoby nie chcą w najbliższym czasie rozstać się z
PLD. Te kilkanaście osób może w ostateczności spokojnie wystarczyć do
spokojnego prowadzenia dystrybycji wg powyższych założeń.



Zmiany organizacyjne... te niestety byłyby niezbędne. Obecna forma
"władzy" w PLD musiała by odejść w zapomnienie... przynajmniej w pewnym
stopniu. Moja wizja zasad zarządzania dystrybucją rozwijaną wg
powyższych zasad:

1. Rezygnacja z jednoosobowej funkcji RMa na rzecz 3-5 osobowego zespołu
osób który:

a) ustalał by założenia, w tym wersje pakietów dla kolejnych snapshotów
b) decydowałby co może (i kiedy), a co nie może (i dlaczego) trafić do
wersji devel, a tym samym w przyszłości do snapshotów
c) wypracowywał kompromisy w przypadku różnicy zdań odnośnie np. "czy
wrzucamy gcc 4.6 teraz, czy dopiero do następnego snapshota"
d) decydował co, kiedy i gdzie przenosić na FTP

Ekipa ta mogła by się nazywać np. RMG - Release Management Group.
Preferowany skład: obecni RMi + wybrane przez nich osoby.

2. Stworzenie grupy kilkunastu deweloperów zajmujących się:

a) przygotowywaniem i posyłaniem na buildery poprawek i aktualizacji dla
aktualnego snapshota z priorytetem dla
b) doprowadzaniem wersji devel do stanu ustalonego przez RMG
c) pomagających poprzez głosowanie razem z członkami RMG w rozwiązaniu
kompromisów, których RMG nie może rozwiązać samodzielnie (np. z powodu
równej ilości głosów za i przeciw danej zmianie w dystrybucji)

Tu można by pozostać przy nazwie CDG, choć pełniona funkcja byłaby nieco
inna. Preferowany skład: stale aktywni deweloperzy na przestrzeni np
ostatnich 6 miesięcy czy 1 roku.

3. Wyznaczenie opcjonalnych FTP adminów, przynajmniej dwóch. Osoby te
wrpowadzały by w życie decyzje RMG w sprawie ruchów na FTP. Oczywiśce
mogą to być po prostu osoby z RMG czy CDG. Jest to dość istotna funkcja
bo można bardzo dużo przy tym napsuć.

4. Stworzenie listy "core" pakietów / zestawów pakietów. Te paczki miały
by priorytet w aktualizacjach i poprawkach jak również niedopuszczalne
byłoby aby trafiły do snapshotów w wersji niedziałającej poprawnie. Mam
tu na myśli rzeczy takie jak glibc, gcc, rpm, kde, gnome, postfix, exim,
mysql, postgresl, bind, squid, dhcp, proftpd, pureftpd, apache,
lighttpd, php, openldap, openssl, samba, clamav itd itd.



To chyba tyle póki co. Ciąg dalszy już ew. w wątku. Zachęcam do dyskusji
i gratuluję tym co doczytali do tego miejca :)

M.