glibc-2.2.4

[Tomasz Kłoczko]

On Wed, 24 Oct 2001, Blues wrote:

> On Tue, 23 Oct 2001, Tomasz Kłoczko wrote:
> > > > > To moze poczekajmy na rpm 4.1 i wprowadzmy go w PLD, ale dopiero w 1.1
> > > > > albo nawet 2.0. To co jest trzeba raczej stabilizowac a nie rozgrzebywac!
> > > > Ja bym jednak wykońał jednak możliwie szybko przejście na db 3.2.x (i 
> > > > zaraz potem na rpm-a 4.0.3).
> > > I znowu, jak to ostatnio masz w zwyczaju (vide: shadow, wczesniej
> > > ncurses,readline,openssl itd., a szczergolnie ac/am), przez kilka tygodni
> > > bedzie totalny balagan w dystrybucji. Wrrrrrr....
> > Jak długo zamierzasz zostać z tym co jest ?
> > Jezli to miał być głos przeciwko zmianom to było to głupie. Wisły kijem 
> > nie zawrócisz. To jest tylko kwestia czasu kiedy ttego typiu zmiany bedą 
> > konieczne.
> 
> A dlaczego mamy tak newralgiczne pakiety jak rpm wprowadzać 2 dni po 
> wypuszczeniu?

rpm 4.0.3 juz wyszedł i nie było to dwa dni temu.
Napisałem, że "możliwie szybko". To nie jest jednak to samo co "jutro 
robimy zmianę na 4.0.3". Sformułowanie "możliwie szybko" zawiera w sobie 
w podtekście klauzulę "tak szykko jak to bedzie możliwe posługując sie 
przy wyznaczeniu terminu rozsądnymi kryteriami które nie narażą całosć na 
niewpotrzebną (czytaj możliwą do pzrewidzenia) destabilizację".

> Przygotowujemy sie do PLD-1.0 - dlaczego nie zostawic w nim rpm'a 
> aktualnego?

Jeszcze raz: napisałem "możliwie szybko" (podkreś tu słowo "możliwie").

[..]
> > > IMVHO zaloz sobie brancha PLD-1.1 i tam rob nowa wersje, z rpm 4.1,
> > > kernelem 2.4 i innymi nowosciami.
> > Jeżeli skolejkujesz w /test wszystkie pakiety do tego to nie bedzxie 
> > kłopotu.
> 
> Dotyczas jakos sie to nie udawalo. I nie wierze, ze tym razem bedzie 
> inaczej

Może teraz wyjdzie. Kiedyś wreszcie musi zaczą ta metodologia działać.

[..]
> Tomku, ile razy zwracano ci TUTAJ uwage w kwesti "radosnego" przerzucania
> z /test _calkowicie_ nierzygotowanych zmian? Zmian, na ktorych wielu
> ludzi, ktorzy czesto zarabiaja na PLD, sie bolesnie przejechali (czasem i
> doslownie, jak przy aktualizacji ssh). I wydawalo sie przy, że okazji
> kolejnych upgrade'ów robisz DOKŁADNIE to samo.
> Z tego tez powodu nie uwierze w takie zapewnienia z Twoich ust, ze 
> "skolejkowanie w /test zalatwi sprawe". Tak _najprawdopodobniej_ nie 
> bedzie.

Przerzucam keidy widzę że zasób wygląda na gotowy. Większść rzeczy zanim
przerzucę staram sie zainstalować przynajmniej u siebie i wyykonać taki
czy inny test na to żeby przekonać sie że jest to vcoś co ma szansę
zadziałać (niemniej na pzreprowadzanei nawet wyrywkowych testów wszystkcih
typów aplikacji juz nie tyle nie mam czasu co nawet warunków ze względu na
to że pakeity te operuja na najszerszym mozliwym spekrum zastosowań).  
Tutaj czasmi musze uwuierzyć osobom które preparowały zasób że jest on
gotowy. Czasmi takze nawet w modyfikacjach jakie sam obie zdaży mi sie coś
sknocić. Co więcej gdyby nawet w procesie podejmowania decyzji brało
więcej ludzi nie dawałoby to pełnej gwaranji że zasób jest gotowy do
uzycia na 100%. Dalej .. używanie tych zasobów od razu po przejściu z test
na maszynkach produkcyjnych jest BŁĘDEM (zrozum to wreszcie). Pewne błędy
bendą wychodzić nie wpierwszej, nie w drugiej instalacji ale w dziesiątej
czy dwudziestej. Każda kolejna instalacja na kolejnej maszynce daje
mneijsze prawdopodobieństwo wystapienia błedu. Popatrz co sie dzieje z RH.
Wypuszczone zostało 7.2 i po mimo tego że zasoby te to de facto coć co
przez ponad trzy ytgodnie nie zmieniało sie (czytaj: było w RH i ludzi
korzystających z rawhide testowane przez ten czas) to juz następnego dnia
po wypuszczeniu 7.2 pojawiły się do tego poprawki w updates.

Zamiast wykonywać "apt-get update; apt-get dist-upgrade; apt-get clean"  
powinienno się na jednostkach produkcyjnych wykonywać raczej "apt-get
update; apt-get dist-upgrade -d" i wykonywać ręcznie rpm -U pakietami
jakie zostaną w wyniku powyższego sciągniete do /var/cache/apt. Ja
przynajmnie sam tak robie.

Tak czy inaczje przenoszenia pakiertów nie dokonuję lodsowo podejmując
decyzję o przeniesieniu na rzut monetą.

> Sumujac - poczekajmy aż PLD-1.1 zrobi zforkuje z wprowadzeniem nowego rpm.

Na razied nie mam żadnych sygnałów z CS o gotowości builderów. Co więcej
nie mam także żadnych sygnałów o tym jaki jest prawdopodobmny termin
ruszenia takowych. Nie chcę z tego na razie wyciągać jakichkolwiek
wniosków ale czas leci.

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*