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

[Ing. Pavel PaJaSoft Janousek]

Milan Kerslager wrote:
> 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

	K tomu jednu pripominku - jak souvisi stabilizace s vyvojem? Mam za to
a Tys Milane tvrdil, ze hlavnim soucasnym ukolem 2.4.X rady je
stabilizacni faze, proti tomu burt, ale proc je tedy snaha (otazka,
zda-li Linus zmeny akceptuje) cpat nove (vyvojove, vyvijene) veci do
2.4.X? Duvod, ze neni 2.5.X prece neni relevantni, bud pisu do supliku a
nebo mam smulu...

	Pro dalsi diskusi navrhuji toto schema oznaceni jader, ktere vychazi ze
soucasneho oznacovani:

2.2. - produkcni (rock stable)
2.4. - stabilizacni
2.5. - vyvojova

> (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.

	Z toho, co pises nyni (a jevi se mi to velice rozumne a nemam duvodu o
tom pochybovat) mi ovsem stale nevychazi to, na co hledam odpoved. Beru,
ze v tuto chvili, kdy nemame vyvojovou radu Linus 'buzeruje' sve ovecky
(treba tim, ze jim komponenty neprijme) tak, ze musi svou komponentu
vyvijet jak pro produkcni, tak pro stabilizacni radu, resp. vyvijet
zrejme ne, ale musi byt schopna behu pod obema systemy. Budiz, ma na to
pravo.

	Prijmeme-li vsak hypotezu, ze mame 3 rady, nejsem presvedcen o tom, ze
by tato podminka byla splnitelna, protoze z urciteho pohledu by byla i
nesmyslna - stabilizacni jadro ma novou verzi komponenty, ktera ma
urcite nove vlastnosti, pokud na to navazujeme ovladace a jsme treba
'temer' donuceni tyto nove vlastnosti pouzit, neni cesta, jak to same
vytvorit v produkcni rade (to uz bychom tam museli dat i tuto 'core'
komponentu). Tudiz v tomto spatruji prvni trhlinu 3 rady = 3 verze
ovladace. Ano, samozrejme i v soucasne dobe mame ovladace, ktere jsou
schopny bezet jak pod 2.0, tak 2.2, tak 2.4 - takze mame 3 verze, ale
jsou to extremy (vyjimky), ktere nejsou bezne a ani zadouci. Pokud nekdo
chce, backporty muze provadet porad a sve patche verejne vystavovat.
Nedomnivam se vsak, ze by 3 aktivne spravovane rady jader nejak
ovlivnily vyvoj.

> v soucasne production rade (2.4.x), nemaji vyvojari kam "utect". Protoze

	Maji - neverim tomu, ze by Linus akceptoval v soucasne stabilizacni
martirii zasadni novinky, a take neverim, ze by se zasadni novinky
nevyvijely (ALSA, CBQ & spol - proste cely networking, ktery bude opet v
2.5 nebo 2.6. prekopany (vrabci na strese si o tom cvrlikaji jiz asi tak
rok (od lonskeho Invexu))), ony se vyviji stale, ale nyni konci v
supliku. Na druhou stranu si ale nemyslim, ze by vyvojari navzajem
nevedeli o techto pripravovanych zmenach (stejne jakozto ja, neaktivni
vyvojar jadra vim napr. o zmenach v networkingu (a ze se mame na co
tesit)) .

> 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

	Ano bic je ucinny (o efektivnosti nediskutuji), je otazka, na kolik
lidi je vsak dopadem, jak rikam, pisi do supliku a soucasne problemy
jsou jim ukradeny...

> 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

	Proti temto slovum nemam osobne nic, co mi vsak vyrazne vadi jsou
skutecnosti, ze v 2.4.X (coby stabilizacni rade) jsou oficialne
vypousteny komponenty, ktere maji oficialne zdokumentovane a zname
chyby. Pokud nebylo nic z toho znamo v 2.4.0 (nechci polemizovat), pak
se to urcite stalo u 2.4.3 (kdy IMHO poprve prislo ReiserFS), toliko za
mou osobu.

> 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).

	Jak jsem napsal vyse, zdanlive to tak muze vypadat, moje osobni
zkusenosti jsou jine.

> "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

	A to je presne bod, ktery povazuji do budoucna za naprosto
neudrzitelny. Vyvojari __musi__ sami svym svedomim, pili a cistotou kodu
(to ze nekteri jsou neskutecny prasata vime, staci zakladni pohled do
kodu, promin, myslis si, ze o takove vyvojare je co stat?, mozna ze
prave skoncili u Linuxu, protoze nikdo jiny je nechce; na druhou stranu
jako vyvojar vim, ze kazdou prasecinu jsem schopen napsat minimalne
jednim 'rozumnym' zpusobem, to mi neodkecas) prispivat ke stabilizaci a
ne aby porad 'vyvijeli' a nekdo jim to stabilizoval - tudy cestu vyvoje
skutecne nevidim.

> 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.

	Ano - spravne rikas pockaji si - tudiz ke stabilizaci neprispeji a
pouze cekaji (nebo pisi do supliku). Koncentrace neni takova, jaka by
IMHO mela/mohla byt.

> 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

	V tomto s Tebou nesouhlasim, hodne zjednodusim, ale myslim si, ze ne az
tak daleko od pravdy:

Management = Linux
Vyvojari = komunita

	Pokud management rozhodne, komunita se musi podridit, uz treba jen to,
ze management neco nezaradi do oficialniho jadra, tak komunita nema
sanci (leda ze by vytvorila paralelni projekt). Pokud by komunita
projevila nevoli (coz obcas dela), v podniku nic nezmuze, muze akorat
odejit. V Linuxu muze co? Rovnez pouze odejit nebo forknout projekt, ne
sesadit management. Nevidim proste ten rozdilny pohled na komercni vyvoj
a toto svobodne sdruzeni. Stejne jako v rozumnem (nerikam ze vsech)
podniku management nasloucha vyvojarum, dela to i Linus, zavery z toho
ovsem vyvozuje pouze Linus nebo pouze management (byt  obou pripadech to
muze byt (je) 1 az N osob).

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

	Nerad bych pausalizoval zrovna v tomto, ja myslim, ze neni jen meritko
pocet odsunutych release datumu, ale rovnez to, z jakeho podhoubi
projekty vznikly. Mam-li byt konkretni, pak napr. u KDE zaznamenavam
pomerne jasny harmonogram, ktery se dodrzuje (na dnech snad bazirovat
nebudeme), rovnez PostgreSQL je na tom velmi dobre a zakladni vzorec
vydavani verzi (major i minor) funguje.

> 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).

	Zapominas na jednu zakladni vec - u vyvojaru na plny uvazek (a tech je
v Linuxu dost) hraje roli i to, zda-li je schopen je nekdo zaplatit. Bud
jsou to distributori nebo vyrobci HW apod., jenze oni ty penize nebudou
nalevat stale, pokud z toho nebude komercni efekt, takze tyto dva svety
byl nedaval uplne od sebe. Samozrejme, ze je spousta lidi, kteri to
delaji pouze pro zabavu, ale tito:
a) nevenuji se na plny uvazek (musi zivit minimalne svoji malickost)
b) nekde jinde pracuji
c) jsou studenti

	Pokud by ses uplnul na tuto kategorii lidi, nic proti, ale ten posun
bude velmi pozvolny. (Napada mne prave jeste skupina velice prachatych,
ale neznam zadneho takoveho Linuxoveho vyvojare...)

> 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).

	Myslim si, ze pro komercni svet je podstatnejsi nez terminy
pouzitelnost, ale jak uz jsem napsal drive, zrejme nejsem dobry manager.

> 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

	Jeden ze zpusobu (zkouska ohnem), jak ziskat kvalitni lidi, proti tomu
nic, neni to vsak jedinny zpusob, jak vybirat/prosevat schopnosti a
kvalitu.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------