MAINTAINER PLD-1.0

[Krzysiek Taraszka]

On Tue, 16 Jul 2002, Blues wrote:

> > Teraz jak to bedzie wygladac w praktyce ? Na ftp pojawil sie juz katalog 
> > updates.
> > W moim zalozeniu bedzie on tym, czym nest jest teraz, czyli stanie sie 
> > podwalina do kolejnej stabilnej poddystrybucji z lini 1.0, powiedzmy PLD 
> > 1.0r1 (albo PLD 1.0.1) To jest do obgadania.
> 
> To już napisałem w innym poście. Konwencja debianowa rX mi się nie podoba. 
> Zresztą - po co sugerować, że się na nich wzorujemy? ;)

tak, to racja, tylko tak zasugerowalem.
IMHO zostaje nam PLD-1.0r1, PLD-1.1 PLD-1.0.1 
Teraz, kto jest za ktorym ? :>
 
> > Zalozenia, ktore musi spelnic pakiet, aby wejsc do dystrybucji STABILNEJ:
> > 
> >     1.  Pakiet usuwa blad bezpieczenstwa.
> > 
> >     2.  Poprzedni pakiet nie instaluje sie, ma niespelniana zaleznosc, badz
> >         skrypty instalacyjne %post %postun
> > 
> >     3.  Pakiet zawiera fix dla krytycznego bledu z BTS, ktory moze zagrozic
> >         bezpieczenstwu, moze zagrozic utrata danych badz pakiet wcale nie 
> > 	dziala, lub dziala ale niezgodnie z zalozeniami tworcow.
> > 
> >     4.  Pakiet musi kompilowac sie i dzialac na architektorach, na ktorych 
> > 	wydane zostala dystrybucja STABILNA
> 
> I tego się należy trzymać.
> Pozostaje jeszcze kwestia co robić jeżeli pojawia się sec-poprawka, ale 
> jest ona dostępna na pakiet o nowszej wersji. Czy łatamy stare (tak jak w 
> debianie i często w RH) czy też wrzucamy nowe? Pierwsze trudniejsze, ale 
> niby lepsze. Drugie łatwiejsze, ale potencjalnie powodujące więcej 
> problemów.

Tak, nad tym sie zastanawialem, i doszedlem do wniosku, ze wieksze 
projekty sa dobrze udokumentowane i zawsze lepiej jest wyciac i poprawki 
dawac do nas, niz bez sensu updatowac do wersji, ktora moze miec wiecej 
potencjalnych dziur niz to co jest obecnie

 > > Zalozenia, czym jest updates a czym PLD-1.0rX (1.0.X)
> >     *   updates/ to katalog z pakietami, w ktorych poprawiono bledy 
> > 	bezpieczensta lub bledy krytyczne, bledy instalacji, etc
> >         Pakiety w updates/ sa traktowane jako podwalina do kolejnej 
> > 	poddystrybucji stabilnej
> >         Pakiet trafiajacy do updates/ musi przejsc faze ra/test (tylko, 
> > 	jesli poprawiony jest proces instalacji, badz poprawka, ktora 
> > 	bedzie wymagala przetestowania)
> >         Nastepnie pakiet trafia z ra/test do ra/updates
> >         UWAGA! Po wydaniu kolejnej poddystrybucji katalog updates/ 
> > 	automatycznie jest czyszczony
> >         Jego zawatrosc przenosi sie do ra/PLD-1.0rX
> 
> Nie.
> To nie tak.
> 
> IMHO należy tylko generować ISO z nowym wydaniem, a updates pozostawić bez 
> zmian. Instalacja sieciowa powinna korzystać z tego katalogu, a instalacja 
> z ISO byłaby normalnie osiągalna. Mniej roboty i prostsze to wszystko.

Zaraz zaraz, male nie porozumienie.
Po pierwsze wg mnie updates/ w swoim zalozeniu bedzie katalogiem, w ktorym 
bede updaty a nie cale distro.
Nasz poldek/apt-get/wuch juz ustawione sa chyba na katalog updates/ wiec 
kazdy instalujacy 1.0 bedzie ssal poprawki z tamtad.
Po drogie iso co 2-3 miesiace, czyli analogicznie, instalujac 1.1 admin 
znowu bedzie bral z updates/ wiec ? stare zeczy znikaja z tamtad, albo ida 
do archiwum (nie mamy tego, trzeba bedzie stwozyc).

> >     *   PLD-1.0rX/ to katalog, ktory zostaje zamrozony jako poddystrybucja 
> > 	STABILNA.
> >         Sklada sie on z propozycji, ktore trafily wczesniej do updates/
> >         Kolejne poddystrubucje przyjmuja odpowiednio kolejne numerki.
> >         X->1,2,3,...,n
> 
> patrz wyżej
> 
> > Teraz czesc osob NAPEWNO zastanawia sie jak by to wygladalo z mojej strony ?
> > Jak bym sie spisal ?
> > Chyba przez ostatni rok mojej aktywnosci w PLD dalem sie zauwazyc jako 
> > czlowiek mlody, ambitny, ale i rozsadny. Z mojej strony nie wyszedl nigdy 
> > pakiet z etykieta STBR jako pakiet niestabilny, nie dzialajacy 
> > (przynajmniej ja nie pamietam ;))
> > Z drogiej strony moja praca wlozona w kernel jest jednak pewnym 
> > wyznacznikiem mojego doswiadczenia i odpowiedzialnosci jakie moge w tej 
> > dziedzinie zaoferowac.
> 
> W poprawne podejście i sposób pracy ja nie wątpię. I chyba nie ma osoby, 
> która ma ci cokolwiek do zarzucenia :)

thx :)

> 
> To jest najważniejsza i najtrudniejsza cześć całego przedsięwzięcia - 
> czas.

Tak, czas .. ale mam czas i bede mial
 
> > Uff, mam nadzieje, ze jasno przedstawilem zalozenia , sadze ze w ten 
> > sposob oddzieli sie linie STABILNA od lini rozwojowej i ze dostane wolna 
> > reke w kierowaniu drzewkiem PLD-1.0rX.
> 
> Ja nie mam nic przeciwko

:))
 
> > W ten sposob odciaze developerow od zawracania sobie glowy linia 1.0,
> 
> ooo - ja myślę, że ludzie ci pomogą. Niektórzy tego używają ;)

tak, tez tak mysle
 
> > oraz pozwole skupic sie im na rozwijaniu lini DEVEL, ktora stanie sie
> > kolejna DYSTRYBUCJA (nie poddystrybucja)STABILNA ( wg mnie powinno to
> > byc PLD-2.0).
> 
> Myślę, że z tego co trafi do devel możnaby stworzyć katalog contrib/ - 
> rzeczy z nowszych release, ale nie wspierane. Skompilowane tylko na 1.0
> IMHO to niezły pomysł.

oo, dobry pomysl. 

Krzysiek Taraszka			(dzimi w pld.org.pl)