Mi a [Linux] kernelfejlesztés folyamata?

Kernel

Greg Kroah-Hartman szerint úgy tűnik, hogy több félreértés is van akörül, hogy hogyan kerülnek be a kódok a Linux kernelbe. Egyesek szerint bizonyos kódok mindenféle ellenőrzés nélkül csak úgy ``becsusszanhatnak'' a kernelforrásba anélkül, hogy ismertek lennének, hogy honnan származnak. Szerinte nyilvánvaló, hogy azok akik ilyet állítanak, még soha nem próbáltak egy nagyobb patchet elfogadtatni a mainline kernelbe. Ha próbáltak volna, akkor nem állítanának ilyeneket...A Groklaw felkérte a Greg K-H-t, hogy írjon egy cikket arról a folyamatról, amelynek során a core Linux fejlesztők patcheket fogadnak el a Linux kernelhez hozzájárulóktól. A cikkben Greg egy piramis ábrán szmlélteti a kernel fejlesztők hierarchiáját, megtudhatjuk, hogy mi a szerepe a ``Signed-off-by:" sornak a levelek végén, stb.

A cikket elolvashatod itt.

( XMI | 2005. 05. 31., k – 18:44 )

Csak ugye a lényeges kérdés az, hogy vajon ha az IBM úgy dönt, hogy kódot ad a linuxba, akkor az is végigmegy-e procedúrán. Mert vannak olyan alrendszerek (pl alsa), amiket többnyire kernelen kívül fejlesztenek és aztán kernel kiadásonként szinkronziálják a külső devel fával a kernelt. Ezeket a szinkronizációkat is olyan szigorúan patch-enként lebontva átvizsgálják a linuxba átvételkor is?

Akkor (és most ne értsen félre senki, nem sco fudolást csinálok, csak kíváncsi vagyok rá), hogy lehetséges az, hogy a JFS olyan formában került be a mainline kernelbe, amilyen formában bekerült. Merthogy iszonyú trágya minősége volt annak, tele volt memory leakekkel (egy időben minden kernel kiadásban volt jfs memory leak javítás, legalább 8 kiadáson keresztül), és elég sok kritikus buggal, ami például nálam egyszer unlinkelhetetlen fileokat majd később teljes adatvesztést is eredményezett. Na akkor hagytam abba a jfs használatát kb 1,5 éve. De ha jól emlékszem kezdettől fogva Experimental megjelölés nélkül szerepelt a kernelben. Ez alapján sajnos arra tudok csak következtetni, hogy a jfs-t a kernelbe különösebb vizsgálat (egy megfelelően felparaméterezett bonnie++ is ki tudott hozni néhány hibát) nélkül merge-elték be.

Csak úgy összehasonlítás képpen a reiser4-et, amit már nem is tudom mennyi ideje tesztelgetnek és már bőven stabilnak tekinthető még mindig nem merge-elték a kernelbe (jó, tudom, vannak akik az új szemantikát nem akarják látni).