maintainer stabilnej wersji

[Lukasz Jachowicz]

tak sie dzis z dzimim zgadalem na ircu, ze on kiedys cos takiego wysmazyl,
to wzialem jego tekst i go "troche" przerobilem. Efekt - ponizej. Any
comments?

Hint: fajnie by bylo, gdyby naprawde powstal komitet techniczny, ktory
decydowalby o sprawach:  1. nie ujetych w innych czesciach nieistniejacych
policy  2. kontrowersyjnych - czyli rozstrzygalby czesc konfliktow itp.
Ale to juz temat na innego maila...

a teraz wypociny. Widac tu jeszcze troche "dzimowatosci", wiec duze (c)
dla niego :)

h.

		RFC dla maintainera wstecznego
		-============================-

I. ZAŁOŻENIA
	Pakiet, aby móc zostać włączony do kolejnej podwersji dystrybucji
	stabilnej, musi spełnić poniższe warunki:

    1.  Usuwa błąd w bezpieczeństwie.

    2.  Poprzedni pakiet nie instaluje się, ma niespełnione zależności
	bądź skrypty instalacyjne %post %postun.

    3.  Pakiet zawiera fix dla krytycznego błędu z BTS, który może zagrozić
	bezpieczeństwu, może zagrozić utratą danych bądź pakiet wcale nie
	działa, lub działa niezgodnie z założeniami twórców.

    4.  Pakiet musi się kompilować i działać na architekturach, na których
	wydana została dystrybucja STABILNA.

Do dystrybucji STABLE trafiają wyłącznie poprawki do istniejących w niej
wersji pakietów, a nie ich nowe wersje. Od tej zasady mogą nastąpić wyjątki
w sytuacji, gdy dany pakiet składa się głównie z błędów. Wówczas może on
zostać zastąpiony nową wersją lub usunięty z dystrybucji stabilnej.
Decyzja w tej sprawie należy do maintainera, który powinien zasięgnąć
wcześniej niewiążącej go rady Komitetu Technicznego.


II. PRAWA I OBOWIĄZKI MAINTAINERA
     Maintainer ma obowiązek dbać o najwyższą jakość i bezpieczeństwo
     dystrybucji stabilnej.
     W tym celu posiada dostęp w trybie rw do odpowiednich zasobów
     na serwerze ftp dystrybucji, a także dostęp do builderów wykorzystywanych
     przy tworzeniu jej stabilnej wersji.

     Dostęp dotyczy tylko wybranych zasobów, które są konieczne w celu
     wypełniania obowiązków, tj:

     1. Katalogi wersji dystrybucji, którą opiekuje się maintainer:

	    dists/
	    dists/ra/
	    dists/ra/updates/

	Prawo do modyfikowania i dodawnia symlinkow w drzewie dists/
	dla zasobow Ra :

	lrwxrwxrwx    1 pldadmin pldadmin        2 Jan 21  2002 1.0 -> ra
	lrwxrwxrwx    1 pldadmin pldadmin        X XXX XX  200X 1.X -> ra

	Maintainer ma również prawo do generowania ISO

	    dists/iso/ra

	oraz prawo do modyfikowania i dodawania symlinków w drzewie iso/
	dla zasobow Ra :

	lrwxrwxrwx    1 pldadmin pldadmin        2 Jan 21  2002 1.0 -> ra
	lrwxrwxrwx    1 pldadmin pldadmin        X XXX XX  200X 1.X -> ra

     2. Bulidery. Na nich maintainer ma prawo usuwac i instalowac pakiety
	wynikajace z zaleznosci budowanego pakietu.
	Maintainer na dostep do nastepujacych buliderow:

	    builder-stable-i386 w pld.org.pl
	    builder-stable-i586 w pld.org.pl
	    builder-stable-i686 w pld.org.pl
	    builder-stable-ppc w pld.org.pl

[A MOZE TO ZASTAPIC HASLEM DO BUILDEROW WSZYSTKICH ARCHITEKTUR, NA KTORYCH
UKAZALA SIE DANA DYSTRYBUCJA?]

IV. DYSTRYBUCJE STABILNE
    Maintainer ma prawo i obowiązek wupuszczania kolejnych podwersji
    dystrybucji STABILNEJ w określonych odstępach czasu. Czas ten nie
    może być krótszy niż miesiąc od wypuszczenia poprzedniej
    poddystrybucji stabilnej. Nie powinien również przekraczać pół
    roku od wypuszczenia poprzedniej stabilnej poddystrybucji, chyba
    że od tego czasu nie nastąpiły żadne istotne poprawki. W przypadku
    braku zgody co do konieczności wydania nowej podwersji, decyzja należy
    do Komitetu Technicznego.


    W celu wydania nowej poddystrybucji stabilnej, maintainer wykonuje
    następujące czynności:

	1. przerzucenie pakietów z dists/ra/updates do dists/ra/PLD/*/RPMS
	   oraz usunięcie ich starych wersji.
	2. wyczyszczenie dists/ra/updates
	3. zmiana symlinków wskazujących na 1.(x+1) -> ra
	4. wygenerowanie ISO
	5. opublikowanie announce na liście pld-announce w pld.org.pl oraz
           poinformowanie osób odpowiedzialnych za kontakty z prasą itp.


V. ZASTĘPCY
    Maintainer ma swoich zastępców, których sposób wybierania reguluje
    odpowiedni zapis w POLICY lub innych dokumentach. Do ich zadań należą
    pomoc maintainerowi głównego oraz zastąpienie go w chwili, kiedy nie
    może wykonywać swoich czynności. Może to nastąpić w jednej z poniższych
    sytuacji:

	1. śmierć maintainera głównego
	2. ciężka choroba lub wypadek mainainera głównego, które
           uniemożliwiają mu wypełnianie obowiązków
	3. odwołanie maintainera głównego
        4. czasowy brak możliwości wypełniania obowiązków przez
           maintainera głównego, na przykład z powodu wyjazdu.

    W tych przypadkach zastępcy mają prawo do umieszczania poprawek
    w dystrybucji stabilnej. Nie mają jednak prawa wypuszczania nowej
    podwersji dystrybucji.


VI. WYBÓR MAINTAINERA
    Maintainer dystrybucji wybierany jest drogą głosowania w chwili
    zakończenia prac nad kolejną stabilną wersją dystrybucji. Pełni
    swoją funkcję do momentu złożenia rezygnacji, zaprzestania prac
    nad starą gałęzią dystrybucji lub odwołania.

VII. ODWOŁANIE MAINTAINERA
    Maintainer może być odwołany jedynie na rządanie innych deweloperów,
    w wyniku głosowania. O konieczności przeprowadzenia decyduje Komitet
    Techniczny na wniosek własny lub umotywowane wnioski części developerów
    dystrybucji.