PLD-1.1

[Krzysiek Taraszka]

A wg mnie PLD-1.1 powinno to byc tylko fixes dla PLD-1.0. 
Do wypuszczenia PLD-1.1 przydalo by sie rowniez stworzyc projekt "Napisz 
dokumentację dla PLD", cos na wzor debiana.
Maintainerem by zostal Sergiusz.

Takie PLD wypuszczone zostalo by po 2-5 miesiacach, jako update tylko.
Ew, mozna takie updaty co pol roku wypuszczac jako PLD-1.1 PLD-1.2

Przygotowalo by sie na ftp'ie katalogi:

dist/1.0 -> ra
dist/1.1 -> ?
dist/2.0 -> nest

I tu juz jest futures, taki aby robic PLD-2.0

W miedzy czasie tworzenia PLD-2.0 (HEAD w repo) w STABLE moze ew poprawiac 
juz zamrozone wersje (np security fixy itp, tak jak to robi debian ...)
i ew w dist/1.1 wrzocac.
I tak przenosic stabilne werje w dist/1.1

Ktos moze zapytac a po co tak robic ?

No wiec juz spiesze z wytlumaczeniem.
Przytocze tu słynnego debiana:

Woody 					Potato
|					|
- rozwijany, super nowosci		- faza STABLE
  itp, itd				- 0 nowosci
- nazwa Debian-3.0			- tylko fixy
					- co pol roku (po nagromadzeniu
					  fixow kolejne rel 2.2.rX)

Jak by to z PLD moglo wygladac ?

Nest					Ra
|					|
- rozwijany tak jak teraz,		- STABLE	
  same nowosci				- 0 nowosci
- po roku, dwoch juz naprawe		- fixy typu security
  dobre distro i stabilne robimy	- co pol roku snapshoty typu
  faze zamrazania			  PLD-1.1, PLD-1.2
- nazwa PLD-2.0				- nadal na kernelu 2.2

Caly czas aktywne by byly indeksy dla nest, dla ra i dla PLD-1.0.

Problematyka by bylo tworzenie iso z PLD-1.1, PLD-1.2.
Trzeba by bylo przenosic zasoby z PLD-1.0 i pozniej nie ruszajac PLD-1.0 
fixowac znalezione bledy w PLD-1.0 jako PLD-1.1, przebudowac indeksy apta 
i poldka i mozna zassyac.
Po pol roku, po nagromadzeniu sie duzej ilosci pakietow (duza = ok 20, po 
co kosmetycznie poprawiac np kde czy gnome  ? o fixy security chodzi mi 
kernel, glibc, demony sieciowe, itp, itd, pracy w sumie malo, moge sie 
zajac opieka kolejnych wersji STABLE)

A jak w tym razie bedzie wygladala praca nad PLD-2.0 ?
A no jak teraz, tzn pchamy nowosci z HEAD, builder buduje, iso sie robi co 
tydzien itpm, itd.

Oto kroki opis branchy jakie mogly by powstac w repo:

HEAD -> PLD-2.0, robimy to co teraz
STABLE -> nasze stable z PLD-1.0, ew dodane fixy dla PLD-1.1
PLD-1.1 -> otagowane pakiety z poprawakami dla PLD-1.0

No i to by bylo na tyle moich wypocin.
IMHO warto takie cos wprowadzic, userzy, ktorym naprawde zalezy na 
stabilnym PLD a nie rozwojowym PLD-2.0 napewno po ukazaniu sie security 
fixes w PLD-1.1 siegna po nie, niz ryzykowac na maszynce jakies problemy 
...

Krzysiek "dzimi" Taraszka			(dzimi w pld.org.pl)