Vyvoj jadra vs. drivery [Was:Re: BugZilla jako zachrana vyvoje?]
Karel Zak
zakkr na zf.jcu.cz
Čtvrtek Listopad 8 10:46:36 CET 2001
On Wed, Nov 07, 2001 at 10:53:56PM +0100, 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
Mel jsem za to, ze 2.4.x je stabilizacni rada. Tedy takova do ktere
se nepridavaji nove veci a je tedy "feature freeze". Opravuji se jen
bugy (uznavam, ze i cela VM muze byt bug:-). Pokud je snaha pridavat
i nove veci tak ta stabilizace muze byt dost nekonecny cyklus. Coz?
Znam projekty kdy vyvojari cekaji (nebo se aktivne pripravuji) na
nove otevreni kodu, ale zmrazeny jiz jen fixuji. A zazil jsem u
PostgreSQL, ze i u bugfixu clovek musel zabojovat pokud to nebyla
nejaka zretelna a fatalni chyba. Nova release (tedy nejdrive beta)
pak byla vyhlasena tehdy, kdyz uz chodilo malo/zadne hlaseni bugu.
Coz znamena, ze vetsinou byl datum stanoven jen orientacne a
upresnoval se dle stavu kodu. Coz mozna na uzivatele dela spatny
dojem (ty odklady), ale pro finalni produkt je to dobre.
> 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).
Za zady mam pocitac s ALSA projektem. Jiz nekolik _let_ se tito
vyvojari zabyvaji vyvojem nezavisle na deni v kernelu. IMHO je uplne
jedno jak se tomu rika, je-li to 2.3.x nebo 2.4.x. Dulezite je jake
patche tak kdo prida (a pridava je tam jen jeden clovek). Ta situace
se vytvori tim, ze se vyhlasi zmrazeni kodu (dobra nekde se tomu rika
production rada:-).
> 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
Skoda, ze tento dostatecne funkcni nastroj nepouzije i na dodani
dokumentace apod. :-)
> Ostatni podobne projekty maji podobne problemy, tj. neustale se odsouvaji
> "stabilni" release (napr. u KDE, Mozilly, XFree86, ...).
Delat si v kalendari znacku u neceho jako je vydani release nejakeho
software je IMHO zakladni bug :-) Jeden muj kamarad rika, ze veskere
casove udaje tykajici se softu je treba zasadne nasobit dvema.
> 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
U mi milovniku kratkodobych investic je datum opravdu dulezite. Obcas
se to, ale pak z dlouhodobeho hlediska prodrazi.
> 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).
M$ neni software firma, ale ucebnicovy priklad perfektniho
managementu a marketingu, ktery v soucasne dobe zrovna dela
do softu (BTW vsimli jste si, ze Bill G. ani Larry E.
neinvestuji _sve_ miliardy do oblasti vypocetni techniky? :-)
Karel
--
Karel Zak <zakkr na zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
Další informace o konferenci Linux