PLD-ng

[Marcin Król]

> TEORIA
> ------
> PLD było by dystrybucją klasy NEST (luźne nawiązanie do dawnego NESTa) i
> _nigdy_ nie było by już stabilizacji typu: instalator+is+wielka pompa.
> Od dawnego NEST-a różniło by się tylko tym że była by to wersja
> _uznawana_ za stabilną. W ten sposób znika ciśnienie do wydania
> dystrybucji.

Hm. O tym samym pomyslalem sobie wczoraj po dyskusjach na pld-users-pl w 
watku "Satbilne PLD". Mysle, ze moglo by to sie nawet przyjac :)

> W efekcie odrzucenie wydawania numerków w klasycznym rozumieniu może się
> przyczynić do większej stabilizacji bieżącej wersji. Nowa polityka PLD i
> pojawienie się w końcu wersji stabilnej (bieżąca==stabilna wg. PLD-ng)
> przyciągnie nowych użytkowników a więc i testerów.

Biezaca ==  stabilna... Zeby tak bylo, musiala by sie zmienic jedna 
rzecz: trzeba by (w przypadku Ac) zaczac uzywac test, ready i main tak 
jak IMO powinny byc uzywane i jak sa uzywane w Ra :) Wszystko leci do 
test. To co wydaje sie dzialac po jakims czasie leci do ready, tam lezy 
powiedzmy 48h i jezeli w tym czasie nikt nie bedzie sie sprzeciwal 
wedruje ostatecznie do main. Ale to chyba malo realne, obecna automatyka 
chyba na takie cos nie pozwala? Ale nie zaglebialem sie w automatyke Ac 
wiec tu niech sie wypowie ktos bardziej biegly w jej temacie.

Poza tym, co wtedy z Th? Byloby stala wersja devel dla powazniejszych 
zmian (glibc, gcc itp)?

> WERSJE
> ------
> Nowy numerek dla dystrybucji dodawany był by bardziej spontanicznie np.
> przy konieczności rekompilacji wszystkich pakietów (nowe gcc?). Stare
> paczki można sobie uważać za "stabilne", "obsolete" lub jak kto woli. 

Do przyjecia. Zwlaszcza, ze ZU powinni moc jakos rozrozniac "nowe" 
wersje. A to mi przypomina... robilibysmy dystrybucje dla ZU czy nadal 
dla developerow (czyli dla siebie)?

> Jeśli ktoś by chciał używać starych paczek jego sprawa, podobnie jesli
> ktoś chce je łatać. W ten sposób nie było by ciśnienia do utrzymywania
> staroci w imię przyzwoitości.

Co do trzymania staroci to jedna rzecz wydawala by sie wg mnie 
konieczna. Katalog na FTP gdzie przy przenoszeniu nowych paczek z ready 
do main te stare z main by wedrowaly na powiedzmy 2 tygodnie. Nie byloby 
problemow z downgrade w razie potrzeby.

> INSTALATOR
> ----------
> Proponuję nie wracać już do tematu INSTALATORA, jest czasochłonny,
> zbędny a i tak przez większość czasu nie do użytku. Wystarczył by
> jedynie jakiś skrypcik instalacyjny, który zautomatyzował by choćby
> część instalacji z Rescue/PLD-Live/chroot-a np. żeby pamiętał za mnie
> konieczność instalacji mod-utils przed kernelem, żeby zawsze instalował
> vim-a itp.

Instalator w formie w jakiej byl dla Ra ma swoje wady. Mozna go 
oczywiscie poprawic i ostatecznie doprowadzic do dzialania, ale 
generalnie jest on i tak skazany na smierc. Czemu? Bo jajka 2.6 z tym co 
niezbednie nigdy sie nie wcisnie na dyskietke 1.44MB. A na 2.4 nie da 
sie w nieskonczonosc jechac.

> Może się zawezmę i napiszę jakieś podwaliny pod Skrypcik Instalacyjny w
> wolnej chwili. Generalnie chodzi o to żeby skrócił czas instalacji z
> dwóch godzin do jednej przy jednoczesnej możliwości odrywania rąk od
> klawiatury, w celu na siorbanie kawy o czwartej nad ranem w
> serwerowni. ;-) (wybacz Patrys, ale szanse na Anacondę są znikome)

Well, to bedzie trzecia osoba robiaca cos do instalacji? :) Ty bedziesz 
robil skrypty do Rescue/Live, Patrys Anaconde, a ja obecny installer 
tudziez prowizorke V2... Moze by tak zamiast tego skupic sie we trzech 
nad jednym z tych wariantow? Np Anacondzie.


> OBRAZY ISO
> ----------
> Do szczęścia potrzebne jest tylko MINI-ISO lub zamiast niego RescueCD z
> dodanymi pakietami z MINI-ISO (w sumie to każdy może zrobić, kiedyś był
> taki skrypt do RescueCD, pozwalający dodawać własne śmieci.

Bo ja wiem czy potrzebne? Ci co uzywaja rescue/live po mini i tak nie 
siegna. A dla innych... Co mialoby sie bootowac z tego mini-iso? Stary 
instalator? A jezeli nic, to po co mini skoro byly by obrazy calosci. 
Gydby miala sie bootowac anaconda, to nie widze czemu nie mialaby sie 
tez bootwac z duzych isos.

> Brak konieczności dostosowywania instalatora pozwałby częściej generować
> płytki ISO (z cron-a?), problemem stają się tylko zasoby dyskowe
> serwerów.

Cron? Nie przesedzajmy. IMO wystarczylo by generowanie raz na miesiac, 
moze nawet rzadziej.

> ZALETY I WADY
> -------------
> zalety:
> - niemal zerowe nakłady pracy, taki stan rzeczy na dobrą sprawę ma już
> miejsce.
> - rozwiązujemy problem wracającego jak bumerang zapytania na listach o
> "wydanie Ac"
> - wyższy niż obecnie ranking PLD pośród ZU (Ac "jest zawsze stabilne"
> zamiast "jeszcze nie jest stabilne") :-)

Z tym wyzszym rankingiem to nie wiem. Watpie zeby nagle wszystkim 
developerom zaczelo zalezec na ZU :)

> Miotacze ognia gotowe? Start! 

:)

M.