W dniu 28 lipca 2010 01:42 użytkownik Marcin Krol <[email protected]> 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 _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
