Diskuze o vyvoji jadra (zmenen subject)

[Stanislav Meduna]

On Thu, 23 Aug 2001 15:32:43 +0000 (UTC), Milan Kerslager wrote:

: z pocatku jsem se snazil poukazat na princip, ale neujalo se. Tak budu
: konkretnejsi. Namodelujeme si pripad, kdy by to melo byt tak, jak
: zaznivaji pozadavky z plena:

OK, dobry napad

: CVS:
: ====
: Hlavnim argumentem pro jeho pouzivani je dle plena moznost sirsi
: spoluprace a to, ze jsou k dispozici ihned patche (tj. veci se nemusi
: strkat do ostre release). Dale pak zaznely pripominky "na blbou nutnost
: deleni patche na male casti".

Hlavnym argumentom je reprodukovatelnost (na jemnejsej urovni,
ako su jednotlive verzie) a dalej informacia, kto, co a preco urobil.
Za pomoci jednoduchych skriptov sa da zistit, co sa v danej
oblasti zmenilo medzi konkretnymi verziami. Situacia typu
"v 2.4.9 to nechodi, naposledy to fungovalo v 2.4.2" sa da
okamzite previest na zmeny medzi tymito verziami.

CVS neznamena, ze donho musi mat kazdy write pristup - zvlast
v stabilnom branchi kludne mozu ist patche cez Linusa alebo
Alana.

: Proti CVS:
: ==========

: Pokud bychom zmenili dramatickym zpusobem model vyvoje, vetsine vyvojaru
: to zacne vadit a odejdou. Mozna prijdou jini, ale jejich zacvik bude dlouhy
: a bolestny.

a) podla mna nejde o dramaticke zmeny, b) ze to zacne vadit
vacsine je sporne, rovnako to moze vela ludi privitat

: Linusovo arogantni lpeni na drobeni patchu je hola skutecnost. CVS zde
: nepomuze, protoze kvuli srozumitelnosti by se commity jednotlivych dilu
: mely oddelovat.

Commity jednotlivych dielov treba niecim spojit. Neviem, ci CVS
pozna pojem "changesetu" - ide o zgrupovanie viacerych suvisiacich
zmien. Ak nepozna, mal by sa hladat system, ktory to pozna -
toto je naozaj u takehoto projektu dolezite.

: (jadro neni jako ucetnictvi, kazda sebemensi chyba muze vets
: k nahodnym katastrofam, ktere nebudou mit primou pricinu).

Toto by sa malo tykat len velmi specifickych casti jadra. Ak je to
typickym pripadom, nieco je zle.

: Jinymi slovy - CVS chce stejnou, mozna dokonce vetsi disciplinu vyvojaru.

Ano.

: Bohuzel, soucasni vyvojari na to nejsou zvykli, protoze aktivni vyvojari
: to proste nepouzivaji. Linus funguje jako spolehlivy filtr a strazce.

... cim sa stava v lepsom pripade bottleneckom, v horsom
"single point of failure".

: Nemusi probirat CVS, staci jen kouknout a zaradit nebo nechat prepracovat.

Alebo zahodit. Netaji sa tym, ze ak ma toho moc, maily
proste zahodi a pocka, kym pridu znovu. Vacsinou tiez
neodpovie, preco nieco zahodil.

: Vysledkem bude pomerne konzistentni projekt s temer jednotnou kulturou.

Domnievam sa, ze jednotna kultura by mala panovat v ramci jedneho
subsystemu; v ramci celeho jadra az tak podstatna nie je. Skor naopak,
tym sa akceptuju vyvojari pouzivajuci rozne styly, takze ich
moze byt viac. Tam je podstatna jednotna kultura rozhrani
a o tu sa skutocne musi starat velmi mala skupina ludi, ktora
je schopna sa zhodnut na pravidlach.

: Problem existence chyb v ostrych releasech neni zavazny.

Namietka. Stabilny branch ma nasadeny spusta ludi, ktori nechcu
alebo nevedia neustale aplikovat patche, tym menej z l-k.
Kym sa rozhybu firmy robiace distribucie a vydaju opravu, moze
uplynut dost dlhy cas.

: Patche jsou k dispozici v l-k velmi brzo,

Namietka c. 2 - 2.4.x napr. inzerovala podporu USB a bol to
jeden z dolezitych motivov na skory upgrade. Zial, na
SMP strojoch zacalo byt USB pouzitelne tak v 2.4.7 - to
je niekolko mesiacov. Podobne IrDA, v 2.2.x bezproblemova,
v 2.4 do cca 2.4.4 nepouzitelna a v tomto pripade ciste kvoli
despotickemu bazirovaniu na minipatchoch napriek znacnej
nezavislosti daneho kodu od zvysku.

: KDB:
: ====
: Argumentem pro jaderny debugger je snadnejsi ladeni jadra.

: Proti KDB:
: ==========
: Debugger prinasi pohodlnost a jasnou tendenci na maskovani chyb.
: Netypictejsim prikladem je Andrea Arcangeli, ktereho Linus sprdaval
: nejmene rok za to, ze dava do svych patchu: if (a==0) then a=1. Bez
: debuggeru se vyvojar musi zamyslet nad kodem a uvedomit si situaci, ktera
: prusvih zpusobuje. Je to obtiznejsi, ale vysledek je dobry - vydrzi jen ti
: nejlepsi, kod je cisty.

Tu som na vazkach - cosi na tom sice je, ale debugger ma aj nesporne
vyhody. U kdb som ochotny akceptovat separatny patch.


: Dokumentace:
: ============
: Jadro nema dokumentaci. To je spatne, protoze se tim tretim stranam
: ztezuje vstup na pole Linuxu.

: Proti Dokumentaci:
: ==================
: Jadro se vyviji zadarmo, bez naroku na odmenu a ve volnem case. Kdyz nekdo
: neco napise, nelze ho nutit, aby delal dokumentaci.

Chyba. Ten, kto nieco napise, je nuteny do spusty veci, kym mu
Linus akceptuje patch. Dokumentacia aspon vonkajsich rozhrani
by mala patrit medzi ne a pokial by bola v predpisanom formate,
najlepsie automaticky udrziavanom (napr. na sposob doc++),
nemusel by vzniknut klasicky problem, ze dokumentacia nesedi
s kodom.


: Binarni kompatibilita:
: ======================
: Duvody souvisi tesne s predchozim bodem - neni dokumentace, kdo to ma pak
: udrzovat (drivery).

:-)

: Proti binarni kompatibilite:
: ============================
: Binarni kompatibilita je brzda, zejmena nutnost jejiho udrzeni a zpetne
: kompatibility. To neumoznuje prizpusobit efektivne rozhrani potrebam
: novych veci (napr. VFS pro ext3 apod).

Taketo zasahy ale nemaju co robit v stabilnom branchi.

: Navic by to vedlo k tomu, ze vendori by uvolnovali binarni drivery.
: Ty se nedaji zkontrolovat ani opravit. Neexistence binarni kompatibility
: vede take k tlaku na uvolneni kodu (nebo alespon jeho vetsi casti),
: cili velke plus pro Linux.

Ciastocny suhlas. Binarna kompatibilita v _stabilnom_ jadre by ale
mala byt _zarucena_. Inak sa podrazaju nohy nielen binary-only
driverom, ale aj vyvojarom, ktorych kod z roznych dovodov nie je
v oficialnom jadre. Prekompilovavat nieco kvoli tomu, ze som
prelozil nove jadro, je PITA (pain in the ass).


: Budoucnost Linuxu je cerna:
: ===========================
: Zejmena pry diky stylu vyvoje. Jadro pry je dnes plne chyb (take diky
: Linusovi), tvurci distribuci vetsinou maji v jadrech 50-100 patchu, ktere
: neco opravuji, takze jadro je v krizi.

Je cierna za predpokladu, ze sa priznaky budu nadalej ignorovat.
QA jadra je prakticky nulova (okrem niektorych modulov, ocenujem,
ze ext3 pouziva regresne testovanie vratane simulacie roznych chyb).
Nechavat to na distributoroch je podla mna chore - namiesto
toho, aby sa o to staral niekto, kto do daneho kodu vidi,
to robia 4 skupiny ludi subezne. Na druhej strane ma komercny 
distributor viac prostriedkov na zodpovedajuce testovacie
vybavenie (rozny hw a.p.).

: Proti cerne budoucnosti:
: ========================
: Je to velmi diskutabilni. Linux je mozna tak uspesny prave proto, ze
: vyuziva vyvojare, kterym to vyhovuje. Patche do jadra se pouzivaly i
: drive. Presne si vzpominam, jak jsem sledoval pred 5-7 lety l-k, aplikoval
: patche rucne (vetsinou opravy nebo ruzna rozsireni) a hledal zminky o
: reseni mych problemu. Dnes to za nas delaji distributori, narocnost na
: stabilitu jadra je vyssi, mnoztvi kodu je vetsi.

Linux je momentalne v tretej etape svojho nasadenia. V prvej
ho bezalo par nadsencov (vratane mna a Teba), v druhej sa uspesne
dostal na trh serverov a momentalne cieli na desktopy a na
nasadenie enterprise rozmerov. Domnievam sa, ze naroky na kazdu
z tychto etap su dost rozdielne a ze by sa im vyvoj mal
prisposobit.


Konecne vecna diskusia...

Zdravi
-- 
                                  Stano