Dlouhy Povzdech: Kde skonci vyvoj Jadra?

[Milan Kerslager]

On Wed, 24 Oct 2001, Pavel Kankovsky wrote:

> > Chyba. Slo o to, ze se zde tvrdilo, ze 2.4.0 je nedostatecna, na coz jsem
> > odpovedel tim, ze 2.4.x je vyvojova rada [...]
>                     ^^^^^^^^^^^^^^^^^^^^^^
> Uh. To myslis vazne? A co byla 2.3?

Jasne. Rada stabilni, ve ktere probiha stabilizace. Tedy presneji
stabilizace zacina uz na konci vyvojove a v urcitem okamziku Linus
prohlasi, ze uz to staci, viz mail z ledna (tj. existuje vyvojova, alfa, i
beta rada):

http://www.cs.helsinki.fi/linux/linux-kernel/2001-00/0802.html

> On Mon, 22 Oct 2001, Martin `MJ' Mares wrote:
> 
> > Zatim tu nepadl jeden, myslim, ze docela zasadni, dotaz: jak si
> > predstavujete, ze by takove testy pro jadro vypadaly?
> 
> Jako na kazdy jiny software, snad s vyjimkou veci, co jsou moc
> blizko hw. Ovsem u jadra specialne by mozna byla velice uzitecne testy,
> ktere by zamerne navozovaly "infarktove stavy" primo manipulaci
> s vnitrnostmi jadra (napr. umele simulovany nedostatek pameti apod.).

OOM problemy se pomerne intenzivne nekolik lidi zabyva. Dokonce to vedlo i 
k napsani vylepseni jadra.
 
> > Nejsou chyby uvnitr jadra obvykle takove, ze je radove jednodussi
> > napsat patch chybu opravujici nez test, ktery ji odhali?
> 
> Chtel bych potkat cloveka, co umi opravit chybu, ktera jeste nebyla
> odhalena. Je rozdil mezi tim, ze vim, ze chyba existuje, a tim, ze vim
> kde ta chyba je. Ovsem kazdy test slouzi predevsim ke zjisteni toho
> prvniho a jen nektere testy (ktere jsou vsak zvlast uzitecne) slouzi
> i k druhemu ucelu.

Kdyz ctu komentare k zaplatam jadra, tak jsou obvykle popisovany pomerne 
specialni pripady soubehu atp., coz se testuje spatne, ale i tim se nekdo 
zabyval (sestrojeni automatu, ktery hledal systematicky chyby).

> > Neco uz existuje: http://ltp.sourceforge.net/
> 
> To vypada docela zajimave. A je ponekud nemile, ze u nekterych testu
> je pomerne dost velky pocet selhani. A to jsou to jen "blackbox tests".

Konferenci l-k proslo nekolik navodu, jak zbourat stroj pomoci chyby ve 
VM, nasly by se jiste i dalsi. Co vim, tak distributori je sbiraji.

> > 4) Nakreslit strom, jak by vyvoj jadra mel vypadat a dat jej do diskuse.
> 
> Ja bych to delal asi takhle: mam verze vyvojove (alfaverze), betaverze a
> stabilni verze. Vyvojova verze se muze zmenit na dalsi vyvojovou, nebo
> muze projit alfa testovanim (ktere neodhali zadne problemy, ktere rada

Tady je problem toho, ze spousta vyvojaru se tomu brani. Nikomu se nechce
psat nic, co by musel udrzovat pro 2 rady soucasne (tj. aktualni vyvojovou
a jeste k tomu stabilni - proto vznikaji backporty). Tim mene bude lidi,
kteri by chteli mit dohromady rady 3 (navic treti rada s pomerne
nesystematicky tristenym forkovanim z rady druhe). Presvedcit se o tom lze
pohledem do L-K, kde si nyni stezuji snad uplne vsichni vyvojari.

Jise, je to hezky napad, ale lidske zdroje na to proste dnes nejsou. Resp.  
jsou - ona ta treti rada je v podstate presne to, co vydavaji
distributori.

> > BugTracking systemy maji distributori. Vyuzij jich, kdyz uz je maji.
> 
> To je sice fajn, ale kazdy distributor ma svuj a tim to konci, coz
> jaksi komplikuje pripad, kdy se jedna o problem, ktery je nezavisly na
> distribuci. Aby to pak nedopadlo podobne jako udajne u jednoho

Jak je videt treba v Bugzille (http://bugzilla.redhat.com/bugzilla), 
bugreporty jsou zhusta predavany zodpovednym vyvojarum nebo dokonce v 
Bugzille pusobi sami vyvojari (Alan Cox u RH Bugzillu sleduje). Asi by 
bylo hezke mit jen jednu Bugzillu, ale zatim neni nikdo, kdo by se o ni 
staral a soucasny system teprve dorusta do prijatelne podoby (kdy by se 
mohl sjednotit).

Oboje jsem tady uz prezentoval a myslim, ze je to zcela jasne videt.

> nejmenovaneho vyrobce databazi, kde kazdy zakaznik dostal opravy jen na
> ty chyby, ktere sam nasel a nahlasil. Tedy on je to problem, ktery se
> netyka jen jadra.

Podle vyjadreni meho kamose, ktery se zabyva Oracle, je to dobre, protoze
kazda hromadna zaplata zpusobi alespon jeden dalsi problem (treba ze
workaround prestane fungovat). Je v podstate radsi, kdyz to funguje takhle
(protoze jinak by bylo slozitejsi udrzet system v chodu). Vetsi fixy se
resi upgradem, kdy jsou na ladeni vyhrazene clovekohodiny.

> > BTW: predpokladat, ze me maitainer bude po zaslani bugreportu zahlcovat 
> >      svymi zaplatami je opravdu roztomile. Nedela to nikdo. [...]
> 
> Zahlcovat zaplatami ne, ale pripada mi celkem slusne a i pomerne caste
> (zvlaste v te casti komercni sfery, ktera jeste neni dost bohata, aby si 
> mohla dovolit vuci zakaznikum bezbrehou aroganci), ze je se mnou veden
> nejaky dialog o tom, jakym zpusobem je mnou nahlasena chyba resena.

Jenze vyvojar, ktery vyviji ve svem volnem case si nepotrebuje vychovavat 
a ziskavat klienty. Sam ma svych starosti dost.

Pozadovanym zpusobem funguje Bugzilla & spol u distributoru. Kazdy dostane
mail, kdyz se neco zmeni.

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