Dlouhy Povzdech: Kde skonci vyvoj Jadra? (bylo: Re: Pozor naMandra

Stanislav Meduna stanom na etm.at
Úterý Říjen 16 10:50:59 CEST 2001


"Milan Kerslager" <milan.kerslager na spsselib.hiedu.cz> schrieb im Newsbeitrag
news:Pine.LNX.4.33.0110160752040.1527-100000 na pluto.pslib.cz...

> BYL tam i Stanuv bod 3 (tusim), ktery (jak tvrdite) neexistoval.

Existoval. Nebol ale dodrzany.

> Mozna by bylo hezke mit bug tracking system, ale ten se hodi na pomaly
> vyvoj a jen obcasne releasy.

Prepac, toto je nezmysel. Samozrejme ze nema vyznam davat tam
bugy typu preklep v mene makra alebo veci, ktore niekto z vyvojarov
zbada a hned alebo v priebehu par dni opravi. Dokonca asi nema
zmysel otvorit moznost zapisu do takehoto systemu komukolvek -
je kludne mozne, aby taketo pravo malo len niekolko ludi (nie nutne
vyvojarov), ktori by urobili vstupny filter. Rovnako mozu byt pravidla
podstatne laxnejsie v pripade vyvojovych serii; najneskor v case
feature freeze by ale uz mal zacat fungovat a od code freeze
by mali platit striktne pravidla.

Priemerny cas existencie skutocneho bugu v jadre ide podla mna
do tyzdnov, ak nie mesiacov (mimochodom, aj toto je zaujimava
statisticka velicina, ktoru ale v sucasnom systeme nejde zistit) -
ci sa vydava release raz za tri dni alebo tri mesiace s tym prilis
nesuvisi. V takom pripade ma obrovsky vyznam, pokial sa clovek
"jednym clickom" dostane ku vsetkym informaciam, ktore su o nom
zname vratane komentarov kohokolvek, kto k tomu ma co povedat.

> Model vyvoje jadra je rychlejsi a udrzba takoveho systemu by sezrala
> tolik casu,

Ano, stalo by to cas. V globale by ho ale urcite usetrila. Nikde nie je
napisane, ze by ho musel udrziavat Linus.

> ze by mohla velmi snadno byt neefektivni (vychazim ze
> zkusenosti s Bugzillou pri stabilizaci distribuce Red Hat, ktere
> se ucastnim), a proto bych ji nepovazoval za spasu.

Domnievas sa, ze bez Bugzilly by bol vysledok kvalitnejsi?

Zdravi
--
                                                        Stano




Další informace o konferenci Linux