PLD 1.0 (troche dluzsze...)

Rafal Cygnarowski rafi w alpha.opm.pl
Pią, 24 Lis 2000, 10:54:20 CET


On Fri, 24 Nov 2000, Wojciech "Sas" Cieciwa wrote:

> > > Moja propozycja jest taka:
> > > Zostawmy rpm'a 3.0, glibc'a 2.1 i kernel 2.2.17, perl'a 5.005, 
> > > python'a 1.X
> > <cyt>
> > W zeszlym roku bylismy o krok od przepasci...
> > ... w tym roku zrobilismy krok do przodu
> > </cyt>
> 
> Masz cos przeciw ???????
> Wydaje mi sie, ze powinnismy cos takiego zrobic.
> Tzn. przygotowac PLD-1.0-i386.iso
> 
> 386 dlatyego, ze wszedzie ruszy.
Kilkanascie maili temu pisalem, ze przydaloby sie zamrozenie pewnej
wersji, dopracowanie jej i zostawienie do czasu, gdy pojawi sie nowa
b. stabilna wersja (tudziez w celach archiwalnych zostawic na stale
w jakims katalogu [PLD-1.0-first-stable (? ;)] np. na task-u - tak
dla przyszlych pokolen).
Nie widze jednak sensu cofniecia sie do starego rpm/glibca/kernela/etc

Pozwole sobie jeszcze napisac tak w ramach propozycji do powazniejszej
dyskusji: moj kolega z pracy (krzyszcz - Krzysztof Sczepanski) stwierdzil
(z czym sie w 100% zgadzam), ze biorac pod uwage stan w jakim jest PLD
i sposob w jaki jest rozwijane prowadzi do tego, ze ta dystrybucja
bedzie przez caly czas dystrybucja dla developerow, ludzi, ktorzy lubia
w niej grzebac przez caly czas etc... W wyniku tego nikt bardziej
rozsadny nie bedzie z niej korzystal bo nie bedzie mial pewnosci, ze
to co pobierze bedzie dzialalo, ba! nawet czy da sie zainstalowac bez
interwecji experta (i bynajmniej nie mam tutaj na mysli bootkietki
- ktora de facto nie zmienia/utrudnia zbytnio instalacji)...

Nie wiem czy dobrze potrafie sobie wyobrazic sposob w jaki powinny
byc prowadzone prace nad PLD, ktorych to efektem bylaby stabilna
dystrybucja, ale na pewno stan aktualny do tego nie prowadzi...
Zawsze jest tak, ze ustabilizowanie pewnych pakietow jest rozstrojone
zupelnie przez wprowadzenie czegos zupelnie nowego, a w efekcie
koncowym caly stan dystrybucji (snapshot z dnia?) do niczego sie
nie nadaje. Wiem, jest to rzecz przeciez normalna, ze zmiany w
jednym miejcu ciagna za soba kaskade innych zmian, ktore w ten
sposob zostaly wymuszone... ale widzial ktos kiedys powazny system
operacyjny, ktory zbudowany po raz XXXX nagle staje sie bez uzyteczny? 
Ja nie! Poza tym pozostaje jeszcze wiele, wiele bledow, ktore sa
ukryte i ujawniaja sie po zaistalowaniu pakietu X z pakietem Y... itd.

Rozwiazanie? Nie wiem czy istnieje idealne, byc moze wskazowka
bedzie takie: ustalic ktora wersja dystrybucji bedzie "Ta Jedyna
Niepowtarzalna I Stablilna" (tm), wyznaczyc w jakich wersjach
powinny sie znalezc pakiety w tejze dystrybucji, doprowadzic do 
takiego stanu, 

for i = 1 to x; do
- wypuscic iso beta$i, 
- kazdy kto tylko moze - przetestowac co sie da, 
- poprawic znalezione bledy
done

jesli stan dystrybucji bedzie satysfakcjonujacy cale grono
zmienic na STABLE i zamrozic. Uaktualnienia do dystrybucji
STABLE nie powinny byc wprowadzane do niej samej, a powinny
byc dostepne jako cos 'obok' wlasciwej dystrybucji.

tematu nie wyczerpalem, ale zanudzac tez nie mam zamiaru,
wiec koncze

pozdrawiam,
rafal

ps. w jakim stanie jest instalator? czy on (i wuch - "juz przeze mnie 
kochany program, aczkolwiej jeszcze nie skompilowany z rpm4.0" (tm) ;)
jest juz gotowy do wspolpracy z rpm 4.0?

                                         __________________________
      rafał 'pascalek' cygnarowski      |                          | 
         mailto: rafi w pascal.pl         | Chwilowy brak sygnaturki |
http://www.kmr.pb.bielsko.pl/~pascalek  |__________________________|



Więcej informacji o liście dyskusyjnej pld-devel-pl