Co by tu zmienic w PLD...

[Bartosz Świątek]

W dniu 28 lipca 2010 01:42 użytkownik Marcin Krol <hawk w limanowa.net> napisał:
> 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 :)
>

Znasz moje zdanie na ten temat :)

I ja się uśmiecham do tego, bo pokrywa to w większości moje pomysły o
których dyskutowałem z Mariuszem parę miesięcy temu.



-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki