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

[Oto Buchta]

Dne po 22. říjen 2001 19:17 Tomas Valousek napsal(a):
> On Mon, 22 Oct 2001, Oto Buchta wrote:
> > Dne po 22. říjen 2001 15:41 Milan Kerslager napsal(a):
> > > Linus nema nad vyvojari zadnou moc ani kontrolu, to je zasadni problem.
> >
> > Sorry, fakt se nemuzu udrzet. Milane. Tak Linus nema kontrolu? A KDO
> > DOPRKENYVOHRADY STRKA PATCHE DO JADRA? Panbuh?
> > On ma prave ABSOLUTNI KONTROLU A MOC. ON je ten sef, ktery MUSI O VSEM
> > VEDET a navic to MUSI DOSTAVAT V PREDZVYKANE PODOBE nekolikaradkovych
> > patchu!!!
>
> A z toho jako podle vas vypliva, ze je ovlada a ma nad nimi kontrolu??????
> Kazdy vyvojar si snad muze a dela co chce.

Ano. Dela. Ale to muze i programator ve firme. Pak je s nim ale stejne 
zameteno jako s clovekem, ktery  pise kod, ktery neodpovida Linusovu 
standardu. Clovek je vzhozen z prace, kod neni obsazen v oficialni distribuci.
Je v tom takovy rozdil?
Pak jsou lide, kteri si mohou ve sve praci delat co chteji, diktovat 
generalnim reditelum velkych firem, proste jsou nenahraditelni nebo tezko 
nahraditelni. Typicke priklady - jadro a AA (kolikrat ho Linus napominal 
kvuli cistote kodu?) oproti jednomu nejmenovanemu cloveku z PVT.net .

> > > Jakekoliv rozhodnuti musi podlehat tomuto kriteriu a prostemu faktu, ze
> > > team lidi, kteri to delaji je promenlivy. Dale nemuze nikomu zadat
> > > zadne ukoly a tim mene dlouhodobe. Jeho osobni zdroje jsou omezene a
> > > pozadavek
> >
> > Jiste ze muze. A dela to. Distribuuje bug-reporty, ktere nepatri jemu. To
> > JE ukolovani, at tomu veris nebo ne. Bugreport od nej je neco jiheo nez
> > bug-report od strejdy Vani z Horni Dolni.
>
> Ale kazdy se muze svobodne rozhodnout, jestli neco bude nebo nebude delat
> a jak to bude delat.

Ano. Muze. Ale neni o jeho svobode, zda se jeho patch dostane do jadra. A 
jeho kus kodu pri spatne udrzbe by mel byt vymenen spolu s maintainerem. To, 
ze se tak mnohde nedeje, jeste neznamena, ze to nelze.

> > > treba na komplexni regresni testy (jinak ze zaplatu nepusti) jsou
> > > nerealne (to by dnes neproslo vubec nic - pro kontrolu jsou k dispozici
> > > [zatim] JINE mechanismy).
> >
> > Ano. A jednim s mechanismu je STABILIZACE JADRA "stabilni" rady. Kdyz
> > nekdo tento mechanismus kritizuje, ty ho hned odpalkujes s tim, ze to tak
> > je a bude a basta.
>
> Minuly tyden jsem si stezoval p. Kerslagerovi, ze se mi zda byt manual na
> hdparm dost neaktualni. Ocekaval jsem, ze mi rekne neco ve smyslu: "Mas
> pravdu, stoji za prd." On sedl k pocitaci napsal:
> cp /usr/share/man/man8/hdparm.8.gz ./
> gunzip hdparm.8.gz
> vi hdparm.8
> Rekl: "Nejlepsi reseni je to upravit a poslat vedoucimu projektu."
> A ma pravdu.
> Jak jste prispel ke stabilizaci jadra?

Ke stabilizaci jadra 2.4 ani 2.2 jsem neprispel nijak. To priznavam. 
Na druhou stranu jsem posilal celkem bugreporty na jadra 2.0 a 2.1. Pak jsem 
se rozhodl prispet svoji troskou do mlyna. Tak jsem do jadra (2.1 hodne 
vysoke verze) prispel patchem na rozchozeni MPU401 pro ALS100 (chybela 
inicializace, tak jsem si lousknul dosovsky inicializator). NIKDY se tento 
patch do jadra nedostal! Duvod? Patch neprosel sitem. 
Trvalo mi to celkem priblizne100 clovekohodin. Jen tak vyhozeno luftem. No, 
jen tak ne, aspon jsem si rozchodil zvukovku. 

Na jadro z distribuce, ktere ji ozivilo, jsem musel cekat az na Alsu a SuSE 
6.4.

Od te doby na jadro neposilam ani bugreporty, pouze upgraduju kernely.

>
> Navrhnete prosim, jak by mel stress-test podle vas vypadat?

Stress test na co? Treba na zvukovku? Ale to je preci strasne jednoduche.
Jsou celkem tri typy moznych testu pro ovladace: Na jednu stranu povesite 
generator "zateze", na druhou stranu bud:
1) primo zarizeni - test v praxi nejlepsi
2) emulator jeho chovani - emulator je napsany tak, aby presne odpovidal na 
funkci podle specifikace. Toto je nejlepsi reseni, ale opravdu se tezko 
programuje.
3) ctecku signalu - rekl bych ze dostatecna pro vetsinu veci.
Pripravite sadu ctveric (data zaslana na vstup ze strany kernelu, data 
prectena ze strany zarizeni, data odeslana zarizenim, data prijata ze strany 
kernelu).
Potom iterujete pres seznam ctveric a pokud nekde dojde k odchylce, mate 
jistotu, ze doslo k chybe.
Pro slozitejsi testy lze ctverici rozsirit o priblizne casy, obsah stacku, 
zatizeni,...
>
> Ja pouzivam na programovani v Perlu vi. Kdyz mi reknete, ze by bylo lepsi
> pouzivat XY, tak se zamyslim, jake ma vyhody vase reseni a rozhodnu se,
> zda budu vami doporuceny vyvojovy prostredek pouzivat. Vam ale do meho
> rozhodnuti VUBEC NIC NENI, zrovna tak vam neni nic do toho jestli, jestli
> Linus pouziva mailbox nebo cvs, jestli pouziva C nebo Basic. Je
> to jeho projekt a vy mu muzete pomoct. Nemuzete ho ale do niceho nutit.

Ja jsem ale uzivatelem produktu! A co vic, rad bych byl i vyvojarem, ale 
proste mi to neni souzeno. Rad bych pouzival a vyvijel stabilni system.
Ale kdyz jsme u vaseho prikladu. Predstavte si, ze po vas budu chtit jako 
uzivatel zmenu, ktera by sla v systemu, ktery pouzivam ja (rekneme nejaky 
case nastroj), udelat za deset minut. A vy si za to nauctujete 50 
clovekohodin! Proc? Pouzivate Perl a vi. jak jste ale spravne rekl, mne jako 
uzivatele to nema zajimat.

Navic mam jeste nekolik dalsich moznosti co s tim.
1) forknout Linux
2) Nepouzivat Linux.
3)Prejet Linuse tirakem.

A rekl bychm, ze dokud se nestane 1) nebo 3), hodne lidi bude delat 2). A to 
je podle mne skoda :-(

-- 
Oto 'tapik' Buchta