Vyvoj jadra vs. drivery [Was:Re: BugZilla jako zachrana vyvoje?]

[Milan Kerslager]

On Wed, 7 Nov 2001, Ing. Pavel PaJaSoft Janousek wrote:

> Tomuto rozumim, ale proc by se tedy v pripade vytvoreni 3 rad jader
> mely u vsech plnit predpoklady a) a b), ktere jsem popsal => proc by se
> mely udrzovat 3 verze komponent? To je otazku na kterou se snazim najit
> odpoved, bohuzel nejak nenalezam - vyvojova oproti
> stabilizacni/produkcni muze byt jina proti tomu nic, ale porad mi to
> vychazi, ze mame stejne jako pri soucasnem modelu pouze 2 verze => nejak
> si nejsem schopen obhajit zakladni tezi: pocet rad = pocet verzi
> komponent a vyssi rezii pri vyvoji (kterou nikdo nechce).
> 
> 	Pomuze mi nekdo, vzhledem k tomu, ze 3 rady navrhl Pavel Kankovsky, ma
> k tomu vyjadreni?

Protoze vyvojar pise stale. Dnes nema vyvojovou radu, takze se snazi sve
zmeny nacpat do production rady (2.4.x). Az bude otevrena vyvojova rada
(2.5.x), tak se vyvojari presunou tam a production rada bude dostavat
akorat bugfixy a vyvojar submitne svuj inovovany driver do 2.4.x jen kdyz
se mu bude chtit.

Protoze dnes vyvojova rada neexistuje a production rada nebude otevrena
drive, nez bude Linus (a ostatni) dostatecne spokojen se stabilizaci kodu
v soucasne production rade (2.4.x), nemaji vyvojari kam "utect". Protoze
vsak spokojenost s radou 2.4.x nedosahla patricneho stupne, tak je
"nasilim" udrzovana rock-stable rada 2.2.x. Je to neco jako bic, proste
Linus vahou sve autority nuti vsechny vyvojare, aby vytvareli skutecne
stabilizujici verze svych kodu a aby se stabilizaci skutecne zabyvali
(kdyz chces psat, tak pis, ale jen to, co je ted vhodne a co potrebujeme).

To je prave ten moment, ktery zde nebyl pochopen - totiz ze zacatek
production rady ma proste jadra dostatecne stabilni (viz citace Linuse pri
vydani 2.4.0 [volne]: I decided that enough is enough), ale neni takovy,
aby s nim mohli byt vsichni uplne spokojeni. Proto se otevrenim production
rady (tj. vydanim 2.4.0) umele vytvori tato situace (tj. vsichni se proste
venuji stabilizaci kodu a nikdo se nemuze zabyvat vyvojem, cili dochazi ke
koncentraci sil na stabilizaci).

Mohlo by se zdat, ze to je zbytecne a slysel jsem zde namitky proti
"nekvalite" 2.4.0 a dalsich 2.4.x, kde x je dostatecne nizke. Ovsem vydani
"dostatecne" stabilni verze (tj. 2.4.0) a zahajeni production rady (ve
vhodnem okamziku) je jediny dostatecne funkcni nastroj, ktery muze Linus
na nezavisle vyvojare pouzit (aby je udrzel u stabilizace). Tyka se to i
pretahovani vyvojaru, kteri se pred tim venovali rade 2.2.x a na 2.3.x
proste kaslali (treba pro nedostatek sveho casu furt sledovat deni ve
vyvojove rade) a vazne se zacali o 2.4.0 zajimat az v okamziku jejiho
vzniku.

Take z toho vyplyva, ze vysokou kavlitou bude oplyvat jadro, ze ktereho se
forkne vyvojova rada (2.5.0) a nebude (resp. ani nemohla) to nikdy 2.4.0
(tj. pocatek teto rady).

Pozadavek pro synchronizovanou release kodu i pro starsi production radu
je take nastroj, kterym se brzdi "rozlet" vyvojaru (implementace novinek
jim nestoji za to a pockaji si az na 2.5.x), cili tlak na Linuse, aby do
2.4.x pustil nejake zasadni zmeny je pak mensi.

Je to porad so tom samem - managment v podniku rozhodne a zamestnanci
proste makaji tam, kde musi. U volneho sdruzeni vyvojaru je potreba najit
motivujici faktor, protoze zaslani mailu "ted budem stabilizovat" je
vicemene neucinne (viz tak hodne propirane Linusovy maily, kde se o to
snazil - treba slib na brzke vydani 2.4.0 nekdy na zacatku lonskeho roku).
On to vi a proto musi manevrovat (coz neni tak jednoduche, jak se muze
zdat na prvni pohled) a jak je videt na minulosti, tak mu to jde (nebyla
by nikdy 1.0.0, 1.2.0, 2.0.0, 2.2.0 ani 2.4.0).

Ostatni podobne projekty maji podobne problemy, tj. neustale se odsouvaji 
"stabilni" release (napr. u KDE, Mozilly, XFree86, ...).

Je to problem, ale jen zdanlive fatalni, protoze dulezite neni kdy, ale
jak to bude ve finale vypadat (tj. jestli se projekt porad posunuje
dopredu). U komercnich organizaci je naopak casovy faktor fatalni a proto
radsi vykopnou featury, ktere se proste nestihnou do terminu (napr. M$ to
ted u Windows XP udelal s USB 2.0 a pravdepodobne i dalsimi vecmi, o
kterych se z principu ani nedozvime).

Dulezite je jen jedno: udrzet ty odsuny terminu alespon v dohlednem
horizontu. Ovsem zde je jako korekcni mechanismus mozno videt
distributory, kteri si najimaji vyvojare, kteri posunuji veci zadoucim
smerem (tj. z hlediska komercniho pohledu).

Pokud se napr. bude Alan nyni venovat vice vyvoji, ktery je zadouci pro
komercni uzivatele Linuxu, bude to jiste dost zajimave (bude to priklad
toho, jak se da jednoduse menit smer vyvoje jadra). Alan ma pomerne
specificky a vlastni pohled na vec, takze se neni potreba obavat, ze by se
nechal uvrtat na neco, s cim by vnitrne nesouhlasil (staci si uvedomit, ze
pokud sekne zamestatnim u RH, tak se o nej ostatni doslova poperou).

Dalsi vec je, ze Alan ziskal misto u RH prave pro svou shopnost hackovani
jadra a stabilizace kodu. Kdyz to ted dostane do rukou nekdo jiny, urcite
stoupne jeho ohodnoceni (podle toho, jak se s tim popere), cimz se opet
podari o kus posunout pomyslnou kvalitativni latku vyvoje jadra (ovsem ne
byrokraticky, ale naprosto pragmaticky).

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager na pslib.cz
                        WWW:    http://www.pslib.cz/~kerslage/