A probléma, hogy a MAINTAINEREK patch -jei sorban el vannak vetve. Ez a fejlesztőket - érthető módon - kiborítja, növeli a különböző kernelfák számát, amelyek fragmentálják a Linux kernel fejlesztését. Ezért Linus -nak szüksége van egy vezetőre, aki segít neki az integrációban.
Létre kell hozni egy hivatalt - a patch penguin -t - amely megkönnyíti Linus munkáját, és amely végeredményben azt teszi, amit Alan Cox tett a 2.4 -ben, és amelyet most nem hivatalosan Dave Jones tesz.
Ha képesek vagyunk megérteni a jelelegi helyzetet - mondja Landley -, akkor jobbá tudjuk tenni a fejlesztés körülményeit, és segíteni tudunk abban, hogy számos problémát megoldjuk a Linux kernel fejlesztése körül.
-- A probléma.
Linus -sal az a probléma, hogy nem egy esetben csendben elveti a patch -eket amelyeket a fejlesztők küldenek neki.
A patcheket amelyek javítják a fordítási hibákat elveti. A kódokat, amelyet az alrendszerek karbantartói küldenek - ezeket maga Linus jelölte ki ezekre a posztokra - elveti. A kernel jelenleg tele van könnyen javítható hibajelzéssel (warnings), ezek mégsincsenek javítva. Ez az állapot frusztrálja a fejlesztőket, a felhasználókat, mindenkit. Ez nagymennyiségű fölösleges munkát generál azoktól a fejlesztőktől, akiknak a patch -jei rendszeresen el vannak vetve. Szükség van az azonnali megoldásra. Gyorsan.
A 2.4 -es kernel kiadása után, eltelt 11 hónap fejlesztői kernelfa nélkül. Fejlesztők egy csoportja közben megalapította a Functionally Overloaded Linux
Kernel (FOLK) project, melynek a célja hogy a fejlesztők által készített, és a Linus által elvetett patch -eknek helyet adjon.
A 2.4 fejlesztése alatt amit Alan Cox és Linus tett a legrosszabb volt, amit tenni tudtak. Alan folyamatosan szállította Linus -nak a patcheket, Linus pedig a mergelési folyamat során nagyrészét elvetette. Vannak olyan patchek amelyek még most sem kerültek be a 2.4.17 -be, sem a 2.5 -be.
-- A megoldás.
A community -nek mentesítenie kellene Linus -t a túlterheltség alól. A patch penguin projectben a vezető (fő maintainerek) lennének kapcsolatban Linus -sal. Erre azért van szükség, mert Linus többször kijelentette, hogy nem óhajt több száz fejlesztővel közvetlenül kapcsolatban lenni. Ez érthető is.
A Penguin Patch Management lehetne egy előszűrő Linus, és a fejlesztők között. A vezetők fogadnák a patcheket, megvizsgálnák őket, majd ezekről rövid jellemzést adnának Linus -nak: "ezt a patchet nem fogadjuk" , "ez nem fordul le" , "ez lefagyasztja a gépem", stb. Így Linus -nak lenne egy puffere, ami előszűrné a patcheket, viszont megmaradna Linus kezében a döntéshozás. Linus lehetne az "építész" a projectben, a vezetők lehetnének a segédek akik a keze alá dolgoznának, de az épület végső formáját Linus szabná meg. Linus vétózhatná természetesen az egészet.
Röviden ez a levél lényege, a teljes levelet elolvashatod itt.
- A hozzászóláshoz be kell jelentkezni
- 1718 megtekintés
Hozzászólások
Nem akarom sem Linus-t, sem Rob-ot bántani. De ennek így baromira nincs értelme.
Ui. Ha Linus eddig a fö fejlesztök _SAJÁT_ patcheit nem fogadta el, akkor most miért fogadná el, a saját pufferelésük után? Gyakorlatilag a team imho hiába írna jó véleményt akár a saját patcheiról, az még nem fogja keményfejüLinust rávenni arra, hogy elfogadja.
Ritkán szoktam radikális véleményt alkotni, de imho eljött az az idö, amikor Linus kezéböl ki kell venni a döntési jogot, és egy több személyböl álló csapatnak adni oda. És vegyük azt is figyelembe, hogy anno Linus megigérte, hogy ha úgy látja, hogy hátráltatja a linux fejlesztését, akkor félreáll, bár elég keményfejü... Imho, meg kell neki mutatni, hogy hátráltatja, és mellé mellékelni saját levelét, és kérni, hogy itt az idö, hogy megtartsa a szavát és átadja a vezetö szerepet egy olyan csapatnak, amiben olyan emberek vannak, mint mingo, ac, rik, és persze a sokat emlegetett stb.!:)
- A hozzászóláshoz be kell jelentkezni
A dolognak ket oldala van.
Az egyik, hogy valoban sok tehetseges fejleszto patch -je kerult sullyesztobe az utobbi idoben. Estenkent bejarok #kernelnewbies irc csatornara, ahol mondhatni hogy a fiatal tehetseges hackerek (riel, dave jones, mjc, stb.) probalnak valami jot alkotni, (pl. riel eseteben ez imho nagyon sikeres is), es bantja oket, hogy havonta 10x darabszamu patchet, fixet, javitast kuldenek Linus -nak, de megcsak valaszt sem kapnak tole.
Aki olvasta a Riel interjut, az lathatta, hogy sorban vetette el Linus a Riel fele VM kodjat, majd kesobb a szemere hanyta, hogy se o, se Cox nem kuldtek neki elegendo patch -et.
A masik oldal Linus szemszoge. A linuxot lassan több ezer ember fejleszti online community -kben. Egy embernek kellene osszefogni a fejleszteseket, es ez Linus lenne. O kontrollalja az aktualis fejleszteseket, majd amikor ugy erzi, hogy a stuff eleg stabil, akkor kirendel mellejuk egy maintainert (lasd. Tosatti). Viszont eddig a pontig neki kell atlatni az egesz folyamatot, neki kell eldonteni, hogy mi kerul bele az uj kernelbe, vagy esetleg mi az, ami kimarad belole. Es a felelosseg eleg nagy.
Valoban itt lenne az ideje, hogy maga kore gyujtse a rutinos, tapasztalt hackereket, es veluk kozosen dontson. Lehet, hogy tenyleg o hatraltatja a fejlesztest.
Szerintem jo otlet a Penguin Patch Management. Meg kellene valositani, mert amint az LKML -en tobben mondtak: "Sokkal jobb munkat lehet vegezni akkor, ha tobb szem nezi a fejlesztesek menetet, mint ha csak egy" - es ezzel a tobbseg egyet is ert.
Ugyhogy lassan Linus -t szorongatjak, elobb-utobb engednie kell, vagy mindenesetre valtoztatni.
- A hozzászóláshoz be kell jelentkezni
En ezzel kapcsolatban csak Ingohoz tudok csatlakozni: igy mukodik es igy kellene mukodnie mindig
Jo ez, ahogy most van, csak a patch-eloknek is aszerint kene mukodni, nem nyavogni. :D
- A hozzászóláshoz be kell jelentkezni
Hello.
Kezdenek "belso" harcok kialakulni, es ez belathato, hogy semmi jora nem vezet. Kicsit olyan a helyzet, mint a kozepkorban. Ha parhuzamot allitunk az akkori kiraly es Linus kozott, donteshozatalban kb. ugyanott vagyunk. Bar voltak kiralyok akik a tanacsadoikra hallgattak, es sikeresek voltak, de az onfejueket altalaban megdontottek. Bar nem vagyok oda a brittekert, de az o modszeruk jelen esetben celravezetobb lenne. A kiralyno csak jelkepes, a fontos donteseket a parlament hozza. Most a vezeto is beleszolhatna (Linus) de a fo donteseket az a 10-20 ember hozhatna akiben megbizik.
Bocsi a tortenelem oraert, de a mondas ugy tartja, hogy a tortelenem megismetli onmagat. Kicsit kiegeszitve azzal, hogy nem biztos, hogy azonos formaban.
Osszefoglalva: Kozosen tovabb juthatnak, mint hogyha 10 10fele mennenek.
Udv.
- A hozzászóláshoz be kell jelentkezni
En azt mondom, hogy Linus sokat dolgozik, a 2.5 korul rendezi a dolgokat. Ahogy a levelben olvashattuk kicsit overloaded lett, ami a munkat illeti. Mivel a 2.5 -os fat keson nyitottak meg, egy csomo patch, fejlesztes keletkezett, amelyeket nem lehetett hova tenni. Ezek kozul szep szammal lennenek olyanok, amelyeknek helye lehetne a 2.5 os kernelben. Ezeknek a patch -eknek a szerzoi folyamatosan kuldozgettek a patcheket Linus, aki szerintem a sok melo mellet nem volt kepes mindet atnezni (valojaban lehetetlen is lenne), ezert drop -olta oket.
Namost elkepzelheto, hogy ha egy nagyobb munkan dolgozik valaki, a patchet elkuldi, es meg csak valaszt sem kap ra, akkor mit erezhet.
Erre Linus mondja (es meg masok is), hogy ott vannak a subsystem maintainerek. Nekik kellene elkuldeni a patch -et, es majd ok kivalogatjak. Ezzel egyet is ertek, csak ez a jelek szerint nem mukodik jol. Mert amig Alan Cox -nak kuldtek a patcheket (az rendszeresen (emlekezzunk hetente 2-3 -ac patchet adott ki, joreszt azokbol amit bekuldtek hozza) addig ezek ossze lettek fogva. De mi tortent ezekkel a patchekkel? Mikor a merge -lesre kerult a sor, Alan es Linus napokig egyeztettek, es a vege az lett, hogy Cox inkabb engedett, es nem veszekedett tovabb (jelenlegi linux VM ugye).
Szoval, a subsystem maintainerek _ha_ rendesen betoltenek a feladataikat, akkor ez jo otlet lenne. BTW ezt akarjak elerni az RFC -vel is, ha valaki jobban elolvasta. Az meg, hogy minek nevezzuk a dolgot: Patch Penguin Leutant -nak, vagy Subsystem Maintainer -nek IMHO tokmindegy.
- A hozzászóláshoz be kell jelentkezni
Egy erdekes reszlet az LKML -ről:
[...]
Remember minix? Way way way back? Andrew Tanenbaum had a little kernel, ran
on intel hardware, came with complete source code. And he did not accept
patches, due to his minix book contract and the resulting licensing issues.
Collaborative development on Linux STARTED in the minix newsgroup, largely by
recruiting people who were frustrated at trying to get their patches into
minix.
[...]
Azt hozza kell tennem, hogy nem levaltani kell Linus. Errol szo sincs. Csak kicsit jobb belatasra teriteni. Mindenesetre a fennti mondetban van igazsag. A linux fejlesztes teljesen kezd szetagazni. Nem kene a Minix sorsara juttatni....
- A hozzászóláshoz be kell jelentkezni
Dehogy fog osszedolni. Es kernel fork sem lesz. Legfokeppen azert, mert Linus nagyon jol csinalja, amit csinal (a leheto legstabilabb kernelt adja nekem - soha nem biznek mas altal keszitett kernelben jobbna, mint az oveben). Hal'Istennek nem anarchia jelleggel folyik a fejlesztese a kernelnek, es hal'IStennek van valaki (Linus), aki megbizhatosagra epit.
Es Alan Cox-ot (helyesen) nem tekinti subsystem maintainernek, amint az kiderult vmelyik lkml-re irt levelebol. Jomagam is azt hiszem, csak egyetlen egyszer probaltam ki egy -ac kernelt, es nagyon izgultam, es amint kijott a Linus verzioja, amiben benne volt az a valami, egybol frissitettem es megfoadtam, hoyg tobbe soha... :) mingo patch-ei eseteben is igy vagyok vle. Alig varom, hogy a 2.4-be portoljak az o1 cuccat.
- A hozzászóláshoz be kell jelentkezni
Huh, azert ezzel nem biztos, hogy minden Alan Cox rajongo egyetert =). Sokszor a 2.4 -es kernel kezdeti lepesei idejen az o patch-jei tartottak a lelket a sok 2.4-es kernelfelhasznaloban. Ez nem a privat velemenyem.
Alan Cox a 2.2-es kernellel kituno munkat vegzett, a 2.2 kernel szikla szilard a mostani allapotban ez tobbnyire Cox-nak köszönhető.
A 2.4-es kernelt jelenleg Tosatti tartja karban, es ne felejtsuk el, hogy Tosatti-t Cox ajanlotta. Es mit csinal Tosatti most? Tobbnyire Alan Cox patchjeit epiti a 2.4-be.
Nem rossz az arc, na. Ez a lenyeg =).
- A hozzászóláshoz be kell jelentkezni
(surun bologatok)
Persze, nagyon jo fej. Egyszer irtam az lkml-re, mert nem futott la a forditas vmiert, es ketten valaszoltak: vm iismeretlen farc, aki leszolt, hogy miert nem olvasok egy vmilyen X helyen levo FAQ-ot, es a masik Alan volt, aki ugy kezdte valaszat, hogy 'It's not your fault', es elmondta, hogy 'make mrproper' a megoldas :)
Es igen, a 2.2-t nagyon jol csinalta (de azt se feledjuk, hogy minden kiadashoz - meg a 2.2-hoz is -, ha jol tudom, kell a Linus beleegyezese.).
Szoval jo fej. De ha Linustree vs. Alantree a kerdes, akkor az Alantree-t csak rovid idore es tesztekre hasznalnam, ha egyaltalan. :)
- A hozzászóláshoz be kell jelentkezni
Lásd a másik hírhez írt kommentem...
- A hozzászóláshoz be kell jelentkezni