Greg Kroah-Hartman munka közben

Kernel

Greg Kroah-Hartman egy videót tett közzé arról a kernelfejlesztői munkafolyamatáról, amelynek során e-mailből patcheket tol be az általa karbantartott -stable kernelfákba.

( fdavid | 2012. 10. 07., v – 10:26 )

Kicsit furcsa volt, hogy meg sem nezte mit fogad el.

( uid_4656 v | 2012. 10. 07., v – 11:05 )

Úgy látom, hogy a befektetett munkának jelentős része olyanokból áll, mint pl. a Subject: sorok manuális szerkesztése. Ha én csinálnám (SOHA!), akkor biztos, hogy inkább automatizálnám vagy másokkal csináltatnám meg ezeket a kozmetikázós részeket :-p

Valószínűleg azt pont nem lehet automatizálni, hiszen emberek írják. De azt hiszem nem ez a jelentős része a munkának, hanem a patch tartalmának átnézése, amit ha jól tudom mind a mai napig Linus csinál egyedül. Ilyen szempontból Greg Kroah-Hartman a "más valaki", aki az unalmasabb részét csinálja :)

Vicces lenne, ha minden pöcsöt ő nézne át "személyesen". :)
Nem követem a kernelfejlesztést, de amit eddig videón Linustól hallottam, az alapján általában legalább van még egy szint alatta, amin keresztül mennek a pöcsök (alrendszer karbantartók). Mindenhez nem ért, ideje sincs mindennel foglalkozni - ezért vannak alatta olyan emberek, akiknek a döntésében megbízik.

( deje | 2012. 10. 07., v – 16:57 )

Komolyan ilyen eszközöket használ 2012-ben? Nem vagyok ellensége terminának és a szöveges alapú progiknak, de ami itt történt, az kicsit meglepett. A hasonló jellegű munkafolyamat nálunk kicsit másképpen zajlik, jóval kevesebb billentyűleütéssel (és egérkattintással) - kissé hatékonyabb szoftvereket használunk.

Mindkettőtöktől kérdezem, mi jelenleg a state of the art hasonló feladatra? Pl. ha kapok valakitől patcheket a projektemhez emailben, és szeretném azokat megnézni (mármint a kész, patchelt kódot), elfogadni, aláírni, stb.?

Szerk. Pl. NetBSD-nél hogy megy át a patch az emailből a CVS-be?

1, Ne email-ben küldje, hanem rögtön verziókezelőben, ha ez még se megy, akkor egy automatikus script azonnal tolja be verziókezelőbe az érkező levelek tartalmát és készítsen belőle task-ot egy issue kezelő rendszerben, ennek a számát írja bele a commit üzenetbe.
2, Ezek után léteznek tök jó code-review eszközök, amelyek kellően vizuálisak és intuitívak, hogy a kód áttekintését kényelmesen és gyorsan lehessen elvégezni, beleértve a visszadobás és az elfogadás workflow-t is, így rögtön meg tud jelenni egy issue kezelő rendszerben a visszadobott vagy elfogadott patch -- és persze lehet rögtön ütemezni, hogy melyik release során adjuk ki.
3, A merge előtti kódon a tesztek automatikus futtatása, kód metrikák automatikus kiértékelése, mint a merge feltétele.
4, A sikeres tesztek és review után a merge lehet automatikus, ha nincs conflict.

Nem túl összetett folyamat, amúgy nem zavar, ha valaki jól érzi magát automatizálható feladat elvégzése közben, csak ne propagálja, hogy ez egy követendő példa.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Es ugye a linkelt cucc opensource? Merthogy ugyebar Linux kernel fejlesztesrol beszelgetunk. Azt mar meg se merem kerdezni, hogy GPL v2 vagy v3 kompatibilis-e a licence, mert van egy tippem a valaszra. A Gerrit viszont az ilyen kovetelmenyeket is rohogve teljesiti.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ebben igazad van, csakhogy ha figyelemmel kovetted a Linux kernel fejleszteset, akkor tudod, hogy Linus, ahol csak lehet, igyekszik GPL eszkozoket hasznalni a fejlesztes soran, es ennek csak az egyik oka az, hogy o az egyik vezeralakja a licenc elkotelezett hiveinek. A masik viszont az, hogy igy szabadon tudja modositani a forrast az o igenyeinek megfeleloen, es vissza is tudja kuldeni azt az eredeti csapatnak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ez a GPL-t leszámítva mind igaz Atlassian termékek esetén. :)

Ha a Red Hat-nak megfelelő a Jira (https://issues.jboss.org/secure/Dashboard.jspa). Az Oracle-nek megfelelő a Jira (http://mail.openjdk.java.net/pipermail/announce/2011-October/000112.html). Sok más Open Source cégnek megfelelő az Atlassian termékpaletta, mert egyszerűen sokkal produktívabb lesz tőle a fejlesztés, akkor miért pont a Linux kernel környékén kell sznob hozzáállás miatt komoly embernapokat azzal tölteni, hogy az előző évszázadból származó eszközökkel oldják meg például a patch-ek kezelését és a code-review-t?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Az atlassian termekek nem telejsen nyilt forrasuak, forrasuk nem toltheto le szabadon, amennyire tudom. Levelezni/kerni kell toluk, es "majd elbiralljak".

Nezd, ezeket a szabalyokat nem en talalom ki. Tessek felvenni Linus-sal a kapcsolatot, es erdemben leirni, hogy ez nekik miert jo/nem jo.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Az atlassian termekek nem telejsen nyilt forrasuak, forrasuk nem toltheto le szabadon, amennyire tudom. Levelezni/kerni kell toluk, es "majd elbiralljak"."

Nem bírálnak el semmit. Élő licenc mellé jár a forrás, egyszerűen minimalizálják az élő munkát, előtérbe helyezve a kreativitást a gépies tevékenységekkel.

"Nezd, ezeket a szabalyokat nem en talalom ki. Tessek felvenni Linus-sal a kapcsolatot, es erdemben leirni, hogy ez nekik miert jo/nem jo."

Tiszteletben tartom a döntéseiket, nyilván futottak pár kört, de a szál onnan indult, hogy "amúgy nem zavar, ha valaki jól érzi magát automatizálható feladat elvégzése közben, csak ne propagálja, hogy ez egy követendő példa."
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Open Source, például az alábbi módon tudsz egy Confluence-t magadnak lefordítani:
https://developer.atlassian.com/display/CONFDEV/Building+Confluence+Fro…

És Open Source projektekhez free:
http://www.atlassian.com/software/views/open-source-license-request

És nem csak az Atlassian közvetlen termékei ingyenesek OS használathoz, hanem az _összes_ plugin... azok is, amelyeket vendor-ok készítenek.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Source code access is available for commercial license holders" :(

Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore... (a 25-fos licensevel, mivel pl van 5 dev, 3 "mindenfele" manager, 2 sysop, X reporter).. sajna marad a gerrit :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Egy 25 fos ceg nem kicsi, ha fejlesztocegrol van szo. 25 ember mar csodat tud muvelni. Kisebb
"Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore"
25 embernek 1 fo felhavi fizeteserol beszelunk. Nehogymar sok legyen. A JIRA es a tobbi Atlassian termek nagyon megeri az arat. Kisebb cegeknek, startupoknak meg ott a 10 dollaros licenc. Ket mozijegy ara.
Aki meg nem tudja kigazdalkodni ezt sem, az inkabb zarja be a boltot.

"Source code access is available for commercial license holders" :("

Open Source licenchez is jár a forrás, én is letöltöttem, mert például plugin fejlesztéshez nagyon hasznos segédeszköz a host forrása.

"Egy kis fejleszto cegnek meg a $1200 egy kicsit sor elsore... (a 25-fos licensevel, mivel pl van 5 dev, 3 "mindenfele" manager, 2 sysop, X reporter).. sajna marad a gerrit :("

10 fős licenc 10 dollár évente. Ennél több nem kell szerintem code-review feladatra kis cégnél. Ha kell a 25 felhasználós licenc -- ami ugye havi $4 felhasználónként és nem fillérekbe kerülő fejlesztőkről beszélünk :), akkor már kigazdálkodható az 1200 dollár is abból a pénzből, amit a gerrit és a crucible használata közben megtakarított embernapokból kijön, pláne ha hozzávesszük a többi Atlassian terméket, amelyekkel nagyon sok manuális munka automatizálható és nem esik le az asztalról semmi, ami beérkezett, mindennek megvan a helye a workflow-ban...

Napi szinten használom ezeket az eszközöket és próbáltam jó pár egyéb eszközt, sajnos nincs jó ingyenes alternatíva (az alapötlet általában egyszerű és könnyen leprogramozható, de normális és használható webes felület nem szokott előfordulni ingyenes eszközöknél), mert hiába ingyenes, ha közben több embernapot elveszt a cég azon, hogy nem használhatók hatékonyan.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Na akkor most gyorsan tegyunk tisztaba dolgokat.

Eloszor is, a sztori onnan indult, hogy kokori eszkozoket hasznalnak a kernel fejlesztese soran. En vetettem fel azt, hogy ezeknel az eszozoknel (ezekhez kepest) egy Gerrit is hatalmas elorelepes lenne. A Gerrit tehat igy kerult a kepbe, en nem mondtma, hogy a Gerrit egy uberalles-fasza rendszer, csak viszonyitottam hozza.

Aztan, ne keverjuk ossze a Linux kernel fejleszteset egy fizetos termekeket fejleszto cegevel. Amennyire tudom, a Linux kernel fejlesztese - legalabbis nevleg - non-profit dolog, a fejlesztok kozvetlenul a Linux kernelen vegzett munkajukert nem kapnak penzt (az mas kerdes, hogy olyan cegek alkalmazasaban allnak, ahol a feladatuk a Linux kernel fejlesztese (is), de ezert, mint allasert kapnak penzt, nem pedig mint pl. a Google fizeti az Android fejlesztoket, vagy a RedHat az OVirt fejlesztoit). Tehat a Linux kernel a sajat fejlesztesere nem termel penzt, a legtobb cuccuk - amennyire tudom - vagy adomany, vagy adott ceg bocsatotta rendelkezesukre.

Ilyetekeppen tehat arrol beszelgetni, hogy a Linux kernel mit tud maganak kitermelni a fejleszteshez, nos ez nem vezetne sehova sem. Itt alapitvanyok vannak meg lelkes kontributorok, de a Linux kernel mogott nincs egy konkret ceg, akit meg lehetne nevezni, mint kvazi "tulajdonost".

Linus is csak koordinalja a fejlesztest, de meg csak az o tulajdonaban sincs a Linux kernel.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Valamelyik alapitvany fizeti a domaint, a hosting gep vagy adomany, vagy valaki szivessegbol hostolja."

Tehát mégis csak van pénz valahol, ha minden kötél szakad... :)

"Amugy az Atlassian mi alapjan donti el, hogy mi szamit opensource fejlesztesnek?"

Nagyjából az a határ, hogy a termék felhasználója számára általános esetben automatikusan elérhető-e a termék forráskódja.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Amugy az Atlassian mi alapjan donti el, hogy mi szamit opensource fejlesztesnek?"

Nagyjából az a határ, hogy a termék felhasználója számára általános esetben automatikusan elérhető-e a termék forráskódja.

Fun fact: mivel az Atlassian termékei opensource szoftverek, ezért azokat az Atlassian termékeinek fejlesztéséhez ingyenesen felhasználhatja az Atlassian. :)

A Linux kernel fejlesztesehez az osszes Atlassian termek ingyen lenne, ugyanugy, mint a Gerrit.
Epp ezert hiaba nagy elorelepes mar a Gerrit is, meg annal is van jobb, ugyanannyi dollarert.
Csak eppen mivel nem FLOSS (de a licencelok szamara, igy a kernel.org-osok szamara is elerheto a forras), ezert nem hasznaljak. A licenchuszarkodassal egyaltalan nem vedheto a kokori minoseg/release management. Mindenesetre ha tenyleg csak a licenc miatt nem hasznalnak korszeru eszkozoket, akkor ne csodalkozzon senki, hogy mindig lesznek regressziok, 1-1 bug kezeleset nem lehet kovetni a forraskodhoz kepest konnyen - nem, a Bugzilla erre nem alkalmas. Az egy rettenetes eszkoz, hasznaltam JIRA utan, mert egy masik cegnel az volt a policy. Hat, JIRA-hoz kepest remalom.

Van meg ott mas technologia is: http://msdn.microsoft.com/en-us/windows/hardware/gg487310.aspx meg ugy a DDK kornyeken erdemes korulnezni.
Masreszt tenyleg, egy 20+ eve fejlesztett kernelnel meg mindig ott tartunk, hogy "hogyan lehet ezt tesztelni?" Elvileg a vilag legjobb szoftvermernokei dolgoznak rajta, nem pedig hobbikoderek. Sot, sokan fizetest is kapnak azert, hogy kernelt fejlesszenek.

1) tudjuk hogyan mukodik a kartya
2) tudjuk mi a driver interfaceja kernel oldalrol
3) tudjuk azt is, hogy hogyan kellene mukodnie a drivernek, milyen teszt esetek vannak, stb.

Ezek jo resze automatizalhato a kernel tobbi resze nelkul is. Attol, hogy ez egy kernel, nem kellene kulonboznie egy modularizalt, tesztelheto sw-nel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Úgy hívják a technológiát, hogy mocking vagy mock testing... munkaigényesebb, mintha nincs teszt, de nem lehetetlen dolog egy hardverszimulátort megírni, amivel tesztelhető a driver, lévén a driver írásához ismerni kell a hardver működését.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Egyetértek. Az átnézés ok, mehet tőlem vi-ben, de ezeket az apró kozmetikai korrekciókat már réges régen egy script-nek kellene végeznie.
Ez így leginkább netto energia és idő pocséklás.

Mindezzel persze egyáltalán nem becsmérlem a munkájukat.
-----------------------------------------------------
MacBook Pro - Mac Pro - PowerMac G4 - Hackintosh

( termih | 2012. 10. 07., v – 20:25 )

Van valakinek ötlete, hogy mivel jelenítette (milyen programmal) a billentyűkombinációkat?

( radix | 2012. 10. 08., h – 12:13 )

erre mondaná ezt az egyik jó barátom, hogy "hatékonytalan".