co z zamrazaniem dystrybucji

[Konrad Stepien]

On Sun, 10 Dec 2000, Tomasz Kłoczko wrote:

> On Sun, 10 Dec 2000, Grzegorz 'Dzikus' Sterniczuk wrote:
> 
> > Czy wiecznie będzie PLD-1.0? Czy zamierzacie kiedykolwiek zacząć zamrażać
> > coś w dystrybucję, szczerze mówiąc wolałbym mieć jakiś podział na release
> > i stable. Sam lubię grzebać i znajdowac błędy ale to mogę robić na własnej
> > maszynie a nie na serwerze, tam potrzebuję stabilności a nie najnowszych
> > wersji. Może przynajmniej podział na stabilne i testowe bo to co czasami
> > trafia do ftp.pld.org.pl/PLD-1.0/i686/PLD/RPMS np. często posiada błedy,
> > które potrafią położyć maszynę (vide kernele 2.2.x i glibc 2.2).
> 
> Moment destabilizacja trwałą kilka dni. Było o tym głośno ale było 

Kilka dni które wstrząsnęły polską :-)))))

> wiecej z tym strachu i atawistycznych strahów niż faktycznego
> zagrożenia. Jeżeli masz coś super ważnego to nie istaluj zasobów z

Ja się trochę boję. Taki przykład, mam ne jednej maszynie jakiegoś
zmajstrowanego na plaster i gumę do żucia sendmail-a. Nie mam czasu
tego poprawić a sendmiala w PLD nie ma.
Na razie na tej maszynie mam stare glibce.

> godzinnym opóźnieniem od momentu kiedy pojawią się na ftp tylko odczekaj.
> Poprostu działaj racjonalnie.
> 
> Jeżeli potrzebujesz stabilności to stabilizuj. Samo z siebie się to nie
> zrobi. Zmiana numerka też sama magcznie nie podziała. Zdajesz sie

Ja się staram (na ile mam czas i porafię).
Problem z tym że tego czasu to mam cholernie mało.

> zapominać, że całość prac nie prowadzą krasnoludki tylko my sami. To, że
> niektórzy robią więcej nie zmienia też faktu, że można w tej sytuacji
> jeszcze popędzać. Widzisz coś do zrobienia -> zrób to a nie mów, że jest
> do zrobienia (co najwyżej konsultuj to z innymi np. tutaj o ile mnie masz
> pewności).
> Teraz pytanie: co Twoim zdaniem jest do ustabilozowania ?
> 
Moim zdaniem, takie coś, że nie wprowadzamy np. nowych bilbiotek
jeśli nie ma potrzeby. Dzięki temu nia mam obowiązku instalować
_każdej_ nowostki jaka się pojawi na ftp, bo bez tego np. nowy bash
mi się nie założy.

> Mówiłem już, że po wprowadzeniu perla 5.6 i OpenLDAP 2.0.x nie będzie już
> w zasadzie nić ciekawego i grubego co mogłoby wpłynąć na resztę zasobów
> .. nawet ewentualne przejście na kernel 2.4 też już mało co zmieni.
> Z perlem jest kupa roboty, a OpenLDAP narazie nie wiedzieć czemu nie chce
> sie budować na 586 i 386.

No i to moim zdaniem super moment na zrobienie frozen.

> Wchodzenie np. KDE 2.x bezie już robione bez zagrożenia dla reszty.
> 
> Kolejne wersje programów są zwykle coraz lepsze i stabilniejsze, z
> mniejszą ilością błędów. Wstrzymywać się z ich wprowadzaniem *nie ma sensu*
> bo powstają zaległości i nie są usuwane błędy które zostały zauważone na
> poziomie poszczególncyh paczek przez maintainerów do których nawet
> niejednokrotnie nie mieliśmy szansy dotrzeć.
> 
No i te nowe wersje często mają nowe błędy (robione na poziomie
poszczególnych paczek).

Sens zamrożenia widzę taki, że mój nakład pracy na utrzymanie serwerów
się drastycznie zmiejszy. Updaty robię tylko wtedy gdy muszę.
Teraz sprawa wygląda często tak, że jak muszę zainstalować
nowy pakiet, to mam nagle 50 pakietów do upgradu.
Często kończy się to tak, że robię backporta do starszej wersji.

-- 
Konrad Stępień          | Hardware is indeterministically reliable.
konrad w interdata.com.pl | Software is deterministically unreliable.
InterData/PKFL		| People are indeterministically unreliable.
PLD Team		| Nature is deterministically reliable.