A Linux fejlesztők semmibe veszik a bugreport-okat?

Kernel

A fenti címmel jelent meg egy hosszabb cikk Jonathan Corbet-től, a Linux Weekly News főszerkesztőjétől, aki jelen volt a múlt héten zajló, zártkörű Linux Kernel Summit (LKS) rendezvényen.
A Linux kernel kiadások minőségéről kevés ember tudna érdemben jobban nyilatkozni, mint Andrew Morton, aki már több éve hivatalosan is a Linux kernel 2.6-os ágának karbantartásával foglalkozik. Andrew az LKS-en általa vezetett ülésen nem nyilatkozott arról, hogy a mostani kernel kiadások egyre jobbak vagy rosszabbak lennének. Afelől azonban nem hagyott kétséget, hogy a kernelfejlesztők tudnának jobb munkát is végezni annál, amit most tesznek.

Ok, na de ki az a Natalie?

Andrew egy ideje jelezte már, hogy akar maga mellé egy kernel bugmestert, aki segít neki követni és javítani a problémákat. A bugmaster materializálódott Natalie Protasevich személyében. Andrew azt mondta, hogy egy olyan "undok személyre" van szüksége, aki a levlistákon lóg, és rákoppint annak a fejlesztőnek a fejére, amelyik nem javítja a hozzá tartozó bugokat. Nos, Natalie nem ez a személy. Viszont ehelyett jó munkát végez a bugadatbázis karbantartásában és a visszajelzések megfelelő személyhez való eljuttatásában. Jelenleg 1 500 nyitott bug van a Linux kernel bugtracker rendszerében. Natalie ezeket tisztítgatja és eljuttatja a fejlesztőkhöz. Ha a fejlesztők válaszolnak, akkor az jó, annak lehet eredménye. De nem sok fejlesztő tesz így.

A probléma sokszor azzal van, hogy sok bugreport egyszerűen elveszik. Bejelentik az alrendszerek levlistájára, de ott elfelejtődnek. [...] Jelenleg 50 megválaszolatlan bugbejelentés van a linux-kernel listán. [...] Linus megjegyezte, hogy sokan már nem is olvassák az LKML-t. A forgalom akkora, hogy követhetetlen és új lista bevezetését javasolta a bugbejelentések számára.

Bővebben a itt.

( kikke | 2007. 09. 14., p – 11:25 )

Nem csak a kernelfejlesztők immunisak a bugreportokra.

Evek alatt a fejlesztok gondolom belefasulnak. Amikor 42 fagyas amiatt, hogy a disztrok ossze-vissza patchelnek mindent, utana egyiken megy a masikon nem, meg 127 loser keptelen rendesen beallitani valami, hogy menjen es el kell magyarazni, hogy mit tegyenek, 527 kerdes arra vonatkozik, hogy mikor alakitjak at a kernelt ugy, hogy szines-szagos-csilli villi legyen, 200 big report hasznalhatatlan, es 10-zel lehet valamit kezdeni.

A 10 valodi hibariporthoz 1000-et kell vegigolvasnod.

Nem hiszem hogy annyira jól állnánk opensource fejlesztőkből, hogy így kéne gondolkodni. Jobb ötletnek tartom azt, hogy a fásult fejlesztőket újraaktivizálja ez a (kedves?) hölgy (?). Meg persze rendet tegyen a bugreportok között.
---
otom sprau kana ticuana sanduo pagnoseresmee

Amíg azért fejleszt valaki, mert szereti csinálni, addig produktív. De ha már mártírnak érzi magát, aki szívességet tesz a plebsnek, akkor ideje szusszanni egyet. Nem abbahagyni, csak pihenni 1-2 hónapot, vagy visszavenni a tempóból. Hamar ki lehet égni különben.

But that's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again.

És majd aki azért kapja a fizetését, hogy karbantartsa (=fejlessze és bugmentesítse) az adott akármit, majd jól jelentkezik a bountyra? :)
Egyébként nem rossz ötlet ez, de inkább akkor jó, ha egy-egy komolyabb feladatot kell megvalósítani, a hétköznapi favágásjellegű bugvadászatnál nem annyira.

adott bug megoldasara is ki lehetne irni, aki megoldja, legyen a karbantarto, vagy valaki, aki odapottyant. az is lehetne, hogy az osszeg x%-at megkapja a karbantarto, aki vegulis comittol, illetve teszteli a patch-et, a korrekt patch iroja pedig a maradekot. ha kollaborativ munkarol van szo, akkor meg szet lehetne osztani, de ez mar kezd kicsit tul maceras lenni erzesem szerint.

ami talan mukodne, hogy 1) bejelentik a bugot, 2) kiirodik ra egy bounty, a kommuniti elkezdi bedobalni a penzt, 3) valaki(k) magukra vallaljak a feladatot, es a bountyt egymas, es a karbantarto kozott elosztjak.

persze ez csak ugy mukodne, ha beleintegralnak a bugkoveto rendszerekbe, es irnanak hozza widgeteket, amit oldalakba, mint pl. a hup is be lehetne agyazni (mint a chipin widgetek).

ha valakit ezert alkalmaznak, akkor gondolom van egy adott feladatkore, abban vagy bennevan az aktiv bugfix, vagy nincs. az volt a kiindulo gond, hogy a fejlesztok nem erzik magukat penzugyileg motivalva, nem?

ahogy en mas fejlesztesekben latom, a bugvadaszat, patch review tipikusan egy olyan feladat, ahol bekapcsolodhatnak ujoncok, a penzdij ezen segithetne.

Nem ertek egyet, es egyetertek. En peldaul szeretek bugokat vadaszni, es atnyalazni a kodot, hogy mit lehetne jobban csinalni benne. Persze van kod, amit abszolut eselytelen javitgatni, es tenyleg from scratch. De ha az ember okosan csinalja, mindent lehet egy bizonyos szinten ujrahasznositani. Egyebkent a legtobb sikeres projektre jellemzo, hogy van egy-ket ember benne, aki keves dolgot fejleszt onmaga, es inkabb bugfixelessel es optimializalassal, a kod rendezgetesevel foglalkozik. Pont azert, mert sajnos a legtobb "fejleszto" osszehanyja a szart, becommitolja (sokszor teszteles nelkul), aztan reszerol a dolog letudva...

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Úgy gondolod, hogy a disztróknak az a kedvenc hobbija, hogy patchelnek ha kell ha nem? Ha működik valami akkor ők se nyúlnak hozzá. Arról nem is beszélve, hogy egy adott disztró felhasználói a disztró bugtrackerébe jelentenek. A disztró kernel fejlesztője jelent tovább az Linux kernel fejlesztőinek. Legalábbis a rendszer így kéne működjön szerintem.

Ha mar megpatchelted a kodot, onnantol kezdve a fejleszto nem azt latja, amit a felhasznalo.

7 eves programozoi palyafutasom alatt rajottem, hogy ez a fajta maintenance nem mukodik. Ha fizetnek erte akkor sem.

Sot, az sem mukodik, hogy a userek 52 kulonbozo Linux alatt, 15 GCC verzioval forditva, 30 KDE/GNOME/XFCE/... ablakkezelovel, 15000 kulonbozo hardver alatt hasznalnak egy programot.

7 ev Krusader toldozas-foldozas alatt az ember lassan megunja, hogy KDE 3.1 alatt megy, KDE 3.2 alatt nem megy, openSuSE alatt megy, Ubuntu alatt nem megy, gcc 2.x-el fordul, gcc 3.x-el crash-el, GNOME alatt kdelibs-sel nem megy, a millio fele KDE/X/... konfiguraciobol 1-gyel nem megy,... Az ember idejenek 90%-a azzal megy el, hogy az ilyen baromsagokat keresgel. Es sosem lesz vege. Mindig kieszel valaki valami hulyeseget, hogy a /usr helyett /opt/kde3 alatt legyen a KDE, ne legyen rendszergazda user,... Hosszu tavon eszmeletlen unalmas.

Szoval ha meg ezekhez hozzaadod az 52 linux disztro patcheleset, a developerek eleg gyorsan el fognak zavarni a fenebe.

Pont ez lenne a diverzitás lényege!

Ha egyszer valami jól meg van írva, akkor tök mindegy, milyen OS-en, milyen gcc-vel fordítva megy. Ha mégse mindegy neki, mert... Akkor tudjon róla a fejlesztő, hogy ilyen-olyan kiskapukat szeret benne kihasználni, és kezelje le mondjuk a ./configure scriptben.

Az hogy opt vagy usr/kde3 megint ./configure opció kéne legyen, és a tisztelt fejlesztőknek le kéne már arról szokni (tisztelet a kivételnek), hogy hányjanak a kódba, mindenféle beégetett statikus szart, ami egyébként runtime vagy compile-time configurációs opció kéne legyen...

A lényeg-lényegó: Te ..... el vagy tévedve! Ha ez kell neked, akkor menjél és fejlesszél' windózra, mert a leírásod alapján az való neked!

> Akkor tudjon róla a fejlesztő, hogy ilyen-olyan kiskapukat szeret benne kihasználni, és kezelje le mondjuk a ./configure scriptben

El kell, hogy keseritselek. Nincs altalanos megoldas. Matyohimzes, az van, de altalanos megoldas nincs.

#if KDE_IS_VERSION( 3,2,0 )
csinald_ezt;
#else
csinald_azt;
#endif

Mondhatni gyonyoru.

( joco01 v | 2007. 09. 14., p – 11:47 )

Ezen a téren azért sokkal jobb egy fizetős support. Azt is lefogadom, hogy annak is sok hibáját lehet megemlíteni, de szerintem még úgy is jobb :)

--
joco voltam szevasz

Hogyne , kedvencem a Cisco

Bejelentesz egy bugot, elismerik hogy tényleg , majd közlik, hogy javítva nem lesz, mert a termék end of life LESZ! 3 hónap múlva, vedd meg az n+1 terméket ami leváltja kvantócsillió dollárért az amúgy kvatócsillió dollárért vett cuccot.

Üdv
Szép

( turul16 v | 2007. 09. 14., p – 12:22 )

Web 2.0-ás bugtrackereket kíván a föld.

( bra | 2007. 09. 14., p – 12:46 )

Natalie Portman (FreeBSD port menedzser), Natalie Bugman (Linux bugmenedzser)...

( iron v | 2007. 09. 14., p – 13:26 )

> [...] és új lista bevezetését javasolta a bugbejelentések számára.

Wtf? Mire talaltak ki a Bug Tracking Systemet, ha nem hasznaljak? Mi ugy elhajtjuk a bts fele a juzert, ha levlistan vagy csatin kuld hibauzenetet, mint a szel. Igy nyilvan elfelejtodik, BTS-ben meg ottmarad, lehet kezelni, lehet tudni, kihez tartozik, stb. Nem uj levlistat beallitani, amin ugyanekkora forgalom lenne...

Bar ez erosen imho...

( BaT | 2007. 09. 14., p – 16:07 )

Olyan jutott eszembe, hogy mi lenne, ha egy kódban bugot találnak, akkor az adott kód bekerülne egy adatbázisba. Erről persze értesítenék a fejlesztőt. Ha a kódot adott időn belül nem javítja senki, akkor egy/több jól látható helyen (widget segítségével) megjelenne, hogy adott kód újraírására van szükség. Ha a fejlesztők jól állnak hozzá a dologhoz, valaki megírja a kódot újból from scratch. Így a kód fejlesztője le lesz cserélve, és nem kell évekig várni arra, hogy majd valaki kijavítja a bugot. Ösztönzéshez lehet használni pénzt is, de nem tudom, a community egy bug kijavítására mekkora összeget adna egy fejlesztőnek...

( jzola v | 2007. 09. 14., p – 23:54 )

gondolom nem új probléma ez hogy bugreportokat nem nézik, és nem is fog változni
főleg úgy hogy azért egyre több user lesz..