pld-i586.iso nie wchodzi na 700MB p?yt?

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Wto, 19 Cze 2001, 05:28:31 CEST


On Tue, 19 Jun 2001, Jan Rekorajski wrote:

> [wtorek, 19 czerwiec 2001], Tomasz Kłoczko napisał(a):
> 
> > On Tue, 19 Jun 2001, Blues wrote:
> > 
> > > On Mon, 18 Jun 2001, Jan Rekorajski wrote:
> > > > IMNSHO lepiej powywalać te rzadziej używane. Ja się mniej boję dyskusji
> > > > (wy już wiecie dlaczego ;>) a bardziej tego że nikomu nie będzie się
> > > > chciało tego robić :( Bo to jest kupa roboty niestety.
> > > 
> > > Moze i kupa (ja sie moge z tym pobawic...), ale wazniejszy jest tutaj
> > > mechanizm przerzucania. Jezeli to ma byc na obecnej zasadzie wrzucania na
> > > ftp'a przez te pare osob to... nie będzie to poprawnie dzialalo.
> > 
> > Bo .. ?
> 
> Bo każdy będzie to robił "po uważaniu"? IMHO wystarczy przygotować
> listę pakietów co-gdzie i się potem tego trzymać.

Tak czy inaczej przerzucanie pakietów z test przez kogoś innego niż ja
zdarza się niesamowicie rzadko. Ergo zagrożenai wynikajace z tego że jest
to robione pzrez kilak osób są marginalne, a faktyczny stan tego co ejst
obecnie i mankamenty tego stau maja inne podstawy.

Co do pakietów to raczje bym był za tym żeby już teraz odsiewać te które
nalezy usunąć. Sztywna lista nie będzie tu dobra bo prawdopodobieńswo
tego, ze pakiet powinien być usunięty jest wprost proporcjonalne do tego
jak długo nie zmianiona wersja gotowego pakietu leży an ftp. Czyli już
teraz należałoby się przyglądać pakietom posortowanym według daty
zaglądając na początek tej listy. Najstarszy to jak na razie:

$ ls -la chkfontpath-1.5-2.i386.rpm 
-rw-r--r--    1 pldadmin pldadmin     8111 Sep 28  1999 chkfontpath-1.5-2.i386.rpm

czyli dystans do "czoła" jest jak widać spory. IMHO przy utrzymaniu
dystansu na poziomie maksimum pół roku nie powinno być kłopotów z
niespójnościami i tym że wpadają zasoby mało używane. Możnaby wrecz jeżeli
już generować na bierząco listę zasobó które zagrożone śa wypadnieciem i
publikować coś takiego. Powinno to dawać zainteresowanym danym zasobem
sygnał, że jeżeli zasób przynajmniej nie zostanie przejrzany i
rzeczywiście ktoś nie umieści tam parafki potwierdzajacej, że nie ma nawet
potrzeby przebudowywać pakiet to mozna bedzie go zostawić. Po upływie
dalej pewnego założonego czasu jakiś automat mógłby "odcinać
ogon" przesuwajac starocie do osobnego katalogu. Sygnalizowanei zagrożenia
wypadnięcia z obiegu mogłoby być sygnalizowane poprzez BTS, który mam
nadzieję, że na dniach ruszy czyli o ile się coś takiego pojawi to zaraz
po tym o ile ktoś będzie miał chęć to bedzie mógł sie zając opracowaniem
małego kawałka skryptu który tego typu robotę będzie załatwiał (na
poczatek typował zasoby w oginie, a w drugiej fazie odcinajacy takze
ogon).
Powyższe wychodzi z założenia, że zasób który był odpowiednio niedawno
aktualizowany jest komuś potrzebny czyli de facto jest to takie tworzenie
listy rzeczy potrzebnych na bierząco co IMHO jest znacznie bardziej
elastyczne, mniej zajmujące uwagę i doprowadzajace w efekcie końcowym do
tego że pakiety bedą dobrej jakości i bedą jednocześnie dobrze spasowane
do siebie.

Dzisiaj^Wwczoraj rozmawiałem z Rafałem na temat stabilizowania całosci.
Rzuciłem w trakcie tej rozmowy, że ma to sens wyłacznie przy sprawnie
funkcjonujacym BTS bez którego na razie nie ma sensu zabierać się za taką
czynność bo zginiemy w natłoku szczegółow, a ilość iformacji które przez
brak BTS giną jest spora. Po uruchomieniu BTS na pewno kwestie zwiazane z
przesuwaniem zasobów z test do podstawowej hierarhi ulegną zaostrzeniu
choć nie byłbym tu dogmatyczny i dopuszczał nie tylko zmiany rel pakietów
ale także i wersji bo proces stabilizowania potrwa cio najmniej dwa
miesiace, a w międzyczasie na poziomie pierwotnych źródeł może być
pousuwanych psporo błędów które umkną naszej uwadze, a które bendą z
punktu widzenai jakości całosci ważne.

Czyli podsumowując...

1) Jak widać BTS będzie potrzebny nam już do conajmniej dwuch ważnych
zadań.
2) W związku z tym, że robota Rafała ma się wstępnie skończyć w końcu
tego miesiąca i że na dniach można spodziewać się uruchomienia BTS i tego
że mamy koniec czerwca wypuszczenia PLD 1.0 mozan spodziewać się nie
szybciej niż w końcu sierpnia. O tym czy bedziemy z całoscią gotowi
wczęsniej czy później beziemy mieli jeszcze czas rozmawiać ale powyższy
termin uznałbym już za mocno prawdopodobny. Pod koniec stabilizowania
trzeba będzie przemyśleć jeszcze i opracować sprawę medialnego
przedstawienia wyników naszej pracy i tego jak, kto, gdzie i kiedy będzie
punktował różne osirodki opiniotwórcze w cele odpowiedniego wyprowadznia
na światło dzinne PLD.

Eny koments ?

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*



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