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. _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl