PLD 1.0 (troche dluzsze...)

[Tomasz Kłoczko]

On Fri, 24 Nov 2000, Rafal Cygnarowski wrote:
[..]
> 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? 

W tej chwili jesteśmy w takim miejscu w którym w zasadzie tego typu zmiany
zostały już wprowadzomne w wiekszości. Pozostało jeszcze przejście na
nowego perla i po tym IMHO jest sens zamrazania pewnej wersji.
Wiązać sie to będzie z odseparowaniem builderów które w razie czego beą
służyć do przekompilowywania pakietów dla takiej zamrożonej wersji i to
wszystko. Mówiąc inaczje droga do zamrożenia jest wyobrażalna i realna.

> Ja nie! Poza tym pozostaje jeszcze wiele, wiele bledow, ktore sa
> ukryte i ujawniaja sie po zaistalowaniu pakietu X z pakietem Y... itd.

To jest zupełnie inna kwestia. To poprostu wymaga używania i zgłaszania
najmniejszych tego typu nieścisłości (poprostu).

> 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.

Jest pewna trudność. Otóż wyłapywanie błędów czy też nieścisłości od
pewnego poziomu szczegułowości wiąże sie z pewnym granicznym poziomem
wiedzy. Zatrzymanie całości wiąże się z rozpoczęciem cofania się. Osoby
które maja pewną wyższą niż granicne doświadczenie i poziom wiedzy chętnie
siegają po zasoby "on the edge". Jezeli po zastopowaniu jednej wersji od
razu bedzie kontynuowane dalsze maksymalne wprowadzanie tego co tylko
najnowsze to od razu grono ludzi z odpowiednim doświadczeniem zmaleje.
Rezygnowanie z aktualizowania do stanu up to date też nie ma sensu
ponieeważ często "nowszy pakiet" znaczy "pakiet z mniejszą ilością
błędów".

Jedyne co jeszcze wydaje mi sie do załatwienia to skompletowanie jakiegoś
zestawu testów jakim muszą być poddane pakiety tak czy inaczej. Np. Na
pewno bezie musiało to być to ze pakiety z konkretnym zestawie bendą
musiały zostać przekompilowane w kupie wsyzstkie razem i taki test muszą
przejść pomyślnie. Może jeszcze dałoby sie coś innego dołozyć w zastawie
testów typu QA.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*