Miért az e-mail még mindig a Linux kernel fejlesztőinek elsődleges kommunikációs csatornája?

Linux

Szebbnél-szebb, jobbnál-jobb fejlesztést segítő, támogató eszközök, online szolgáltatások, weboldalak világában élve felmerülhet a kérdés, hogy a Linux kernel fejlesztői miért függenek még mindig olyan ósdinak, idejétmúltnak tűnő kommunikációs csatornáktól, mint az elektronikus levelezés és a levelezési lista. Greg Kroah-Hartman a Kernel Recipes 2016 rendezvényen "Patches carved into stone tablets …" előadásában arról beszélt, hogy miért az e-mail a legjobb módszer a Linux kernel méretű projektek kezelésére.

Részletek az LWN.net összefoglalójában.

Ha a patch amúgy jó, akkor valószínűleg meg lehetne találni a módját, hogy a javítás bekerüljön a kernelbe.

Amig én látok, az két egymásnak feszülő egó:
"Then this change will never be accepted." <--> "next generation of programmers, who use GitHub rather than mailing lists"

Nyilván létezik a mindenkinek elfogadható megoldás, ha a szereplők akar(ná)nak tenni az ügy érdekében.

Csak ott megy felre a dolog, hogy az e-mail is egy kb. mondhatni industry standard.
Kicsit regebb ota, mint a github; ami meg durvan egyszerusitve, egy linus-ek git-jere irt webfelulet.

Az meg, hogy az illeto balf@sz, es ugy konfiguralja a levelezoszerveret, hogy a levlistakat, mint egy alapveto lehetoseget amit az email protokolljat leiro rfc kinal, elutasitja, az megintcsak az o inkompetens faszsaga.
Spam-ok ellen vajmi kevesse hatekony.

ha jol emlexem, akkor kadlec-nek volt egy nagyon jo mondasa regen: a spammereknek van a legszabalykovetobben kitoltott spf/dkim/whateverbullshit rekordjuk az egesz interneten.

Szoval, szerintem pont jo helyen es talan meg idoben altak neki a gyerek egojat letorni.

Nekem nem kell bemutatni az "újhullámos" github fejlesztőket és azt a jelenséget, ahogy lenézik (*) az "old-school" kollégákat és nem is hajlandóak/tudnak nagyon a kényelmes megoldásról már lemondani.

Arra akartam csak reflektálni, hogyha a javítás amúgy megfelelő minőségű, akkor érdemes lenne módot találni a beemelésére. Ebben a formában ez "elveszett" a közösség részére, leszámítva a buhárálós keveseket.

(*: vigyázat, a hozzászólás durva általánosítást tartalmaz)

Az a baj, hogy a ket mentalitas egy es ugyanaz, az "ujhullamosak" lenezik az "old-school"-okat es ugyanez visszafele, es ez az igazan szanalmas. Ha valaki nem tud haladni a korral a preferenciaitol fuggetlenul, annak a jovoben kellemetlensegei lesznek, szamosan.
--
Blog | @hron84
Üzemeltető macik

Mint mindig, valahol középen van az objektív igazság, bár úgy érzékelem, hogy a megrendelői igények az újhullámos mentalitásnak kedveznek az utóbbi időben.

Azon lehetne vég nélkül vitázni, hogy ez jó vagy nem, mennyi plusz kockázat jön be, viszont mennyit ad hozzá a produktivításhoz a modern eszköztár.

Az, hogy az emberek nem tudnak levelezni.

- telefon csörög: "szia, küldtem neked levelet!"
- messenger csipog: "küldtem levelet, megkaptad?"
- "ez a levél a kismiska6000 vírusírtóval lett 86099-szer leellenőrizve, védje ön is levelezésést kismiska6000-el, bla bla bla"
- "ezen levél kinyomtatása esetén a jóisten kinyír 1 nagyon cuki kiscicát, kérem ne nyomtassa ki."
- aláírások, képként.

Lehetne még sorolni. Összességében kevés gusztustalanabb, és zajosabb kommunikációs csatorna létezik, mint az e-mail.

Én azért hozzátenném ezt is, mint ami külön fokozza a zavart. Persze ez is csak egyéni vélemény, mint az összes többi.:-)

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Ez hulyeseg. Akkor lenne igaz, ha ezek az emailek
1) kontextus nelkul lennenek
2) nem egy levlistarol beszelnenk, ahova az emberek eleve azert iratkoznak fel, hogy visszakovethessek a sztorit.

Akinek nem megy a top-posting, annak ott vannak (legrosszabb esetben weben) az elozmenyek. Es tudod mit, az elozmenyekben nem kell legorgetni az aljara, eleve ott van a tetejen a komment.

Aminek talan van meg realitasa, az a middle-posting, vagy mi ennek a neve, amikor a quoted szoveg utan valaszolsz.

De nincs borzasztobb, mint egy tobbszaz szalas kommentfolyamban atgorgetni ket tonna olyan szoveget, amit mar olvastam.
--
Blog | @hron84
Üzemeltető macik

+1

Kezdetben nem szerettem a top-posting-ot, de ahogy az ember elkezd sokat e-mailezni, rájön, hogy praktikusabb. Az előzményeket úgyis ismered, témában benne vagy, ne kelljen már az előzményeket mindig átgörgetni.

Nagyon összetett témákban, ahol sok pontra kell választ adni, mid-postingot alkalmazunk, színezve. A top részen mindig hivatkozzuk, melyik az új szín.

De jó neked, hogy oly kevés levelet kapsz, hogy minden szálban tudod kapásból, hogy pontosan miről szól, hogy jutott el odáig, stb. Nekem sajnos már rendszeresen elő kell szedni az előzményeket, és nincs is jobb, mint ezt így olvasni:

13.
14.
10.
11.
12.
6.
7.
8.
9.
4.
5.
1.
2.
3.

És igen, sorszám szerint növekvő sorban kellene haladni :-))))

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nekem altalaban az osszes elozmeny megvan, es az e-mail kliensem van olyan cuki (meg az osszes webes levlista felulet is), hogy idorendben is kepes sorbarendezni oket. Igy amikor elozmenyt olvasok, akkor vegigkattogtatom az osszes levelet, igy nem lehet olyan, hogy peldaul valaki veletlensegbol/rosszul ertelmezett helysporolasbol beletorolt a szal kozepebe (erre is volt mar pelda).

Ha nincs meg az osszes elozmeny, akkor meg altalaban ugyis megkerek valakit a szalbol, hogy roviden foglalja ossze, mi tortenik most. Persze, ez utobbi csak nem-levlistak eseten mukodik.
--
Blog | @hron84
Üzemeltető macik

Ha egy top-posting szalban mindenki top-postol, akkor nincsenek ilyen csavarok. A csavarok mindig akkor jonnek be, amikor valaki pedagogiai celzattal vagy pusztan vakhitbol bottom-postol. Mert tokmindegy, mi a preferenciad, illik a helyi kommunikacios formahoz igazodni.
--
Blog | @hron84
Üzemeltető macik

Fent szereplő számsorrend egy valódi top-post szövegkupac inline és bottom-post nélkül. De itt van kicsit több szöveggel egy talán még érthetőbb példa. Kérlek olvasd el a lentieket növekvő számsorszám szerint, hátha megvilágosulsz, hogy mit is akarok mondani. A zárójelben segítség szerepel arról, ki mondja az éppen aktuális szöveget. A valóságban top-post levelekben se sorszám nincs (ami megkönnyíti az olvasás sorrendjének kiválasztását), se minden sor elején jelzés arról, hogy ezt ki írta. Helyette vannak a színek (amit vagy úgy lát a partner vagy nem), meg "Az Úr 2016-ik eszdendejében Gombóc Artúr írá" jellegű baromságok. (A valóság ettől a példától annyival rosszabb, hogy nem egyszavas sorok, hanem sokmondatos sorok állnak a levélben - amit a használt levelező függvényében tördelnek el itt-ott.)

Jó szórakozást!

11. (zahy) Látom,
12. (zahy) többedik
13. (zahy) magyarázatomra
14. (zahy) sem
15. (zahy) érted
16. (zahy) mi
17. (zahy) a
18. (zahy) baj a
19. (zahy) top-posttal.
6. (hrgy84) A
7. (hrgy84) top-post
8. (hrgy84) kurva
9. (hrgy84) jó
10. (hrgy84) dolog.
1. (zahy) Szerintem
2. (zahy) baj
3. (zahy) van
4. (zahy) a
5. (zahy) top-posttal

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Kenyelmesen el tudtam olvasni.

Egyebkent altalaban a normal emailnel van vagy kacsacsor a valaszok elott, vagy indentalva van valahogy (HTML leveleknel van ilyen), a poszt elejen meg altalaban ott van, ki mondja.

Zahy, en elhiszem, hogy neked nehezedre esik olvasni, nekem is van, amit nehezemre esik olvasni, de a top-posting pont nem ez. Valoszinuleg azert, mert en mar ezen szocializalodtam. En nem te vagyok, es nem tudok a te fejeddel olvasni. En nem arrol akarlak meggyozni, hogy a top-posting jo, hanem arrol, hogy nem feltetlenul ordogtol valo, van akinek meg az a kenyelmes, es a bottom-posting kenyelmetlen. Viragozzek minden virag.
--
Blog | @hron84
Üzemeltető macik

Még szerencse hogy önmagad megmagyaráztad, hogy miért szar a top-post (az adott esetben meg pláne).

1) mert a levelek *nem* kontextusnélküliek - azaz tök fölösleges 1milliószor beidézgetni mindegyik levélbe
2) a levlista archívumban pont visszakövethető minden - azaz tök fölösleges 1milliószor beidézgetni mindegyik levélbe

De megnyugtatásul jelzem, szerint az inline-posting az üdvözítő, de egyre több olyan környezet van (az MS-féle Outlook és a Google Mail az élen), amely miatt eléggé háttérbe szorult. Egyébként én még így tanultam, és még így tanítom a levelezést:
- inline posting, (oda és azt, ahova és amihez tartozik)
- minden fölösleges sallang törlése az idézés során

Persze volt már olyan ember, aki nem is értette. (Szerintem amúgy a sor-elején | vagy épp > tök jó volt, amíg el nem kezdték ezt a levelezőprogramok "okosabban" megoldani az idézést. Pl. a pink által emlegetett színekkel, ami kurva jó, kivéve ha nem ugyanolyan környezetben olvassa a túloldal, mint a küldő. No akkor aztán szopás a köbön.

> De nincs borzasztobb, mint egy tobbszaz szalas kommentfolyamban atgorgetni ket tonna olyan szoveget, amit mar olvastam.

No hát ezért nem kéne minden rohadt levélben minden szart bennehagyni.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Itt nincs olyan, hogy más környezetben olvassa. Worldwide szinten Lotus-t használ az egész konszern.
A > tényleg jó volt, magam is szerettem. Kivéve, amikor bután volt kezelve, és >>>>>>>> lett belőle a sokadik fordulóban.
Kb. a > funkcióját veszik át a színek. Pl. sötétzöld az új szín annyit tesz, mintha > után volna minden, ami nem sötétzöld, és a sötétzöld az in-line.
Színek nélkül nagy leveleknél ez szerintem szopás.

En azert szeretem, ha be van idezve, mert a GMail feluleten kivul semelyik e-mail kliensben nem lehet szepen elkezelni azt, hogy egyszerre egy ablakon belul lasd az elozmenyt is, meg az eppen irt levelet is. Halalosan gyulolom, amikor ablakot kell valtanom, hogy visszaolvassam/beidezhessem az elozmenyt.

Es hat nem mindenutt lehet GMailt hasznalni.
--
Blog | @hron84
Üzemeltető macik

Lehet, hogy nem értem, hogy mit akarsz, de én úgy emlékszem, hogy az összes mail kliensben, amit valaha használtam, amikor rábökök a válasz gombra, akkor ott van az ablakban az előzmény.

Igény szerint az ember közé, alá, fölé írhat, kitörölheti, ami már nem kell.

Ablakot váltani? Hová? Minek?

Most amúgy nagyon szépen bemutatjátok, hogy az újhullámos suhancok miért küldik el a pokolba az emailt: nem egy jól strukturált valami, minthogy egy github page, hanem egy strukturálatlan szöveghalom és kézimunka tömkelege.

Biztos velem van a baj, hogy szeretem szépen strukturált környezetbe helyezni a dolgokat, ahol követhető, hogy ki mire válaszolt, ki melyik kódsort kommentelte meg - sőt eleve a kódsor rendesen színezett, átlátható, vagy akár kereszthivatkozásokkal tarkított. Vagy ha mondjuk belejavítok valahol a pull requestemre, mert kérték, hogy tegyem meg, akkor automatikusan hozzáfűzi a rendszer a pull requesthez, stb.

Na, aki ezek után levelezni akar, meg kézzel szívni az menjen sajtreszelővel recskázni, ne szoftvert fejleszteni. Lassan 2017 van, nem 1991 haladjunk.

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

Az email-lel semmi, azzal, hogy patch management rendszernek használják már annál több. Az LWM-es poszt alatt az egyik kernel maintainer elég jól összefoglalja, neki mi baja van az egésszel. Meg hogy github után nem használná újra. ("But I've worked in large github projects now for fun, and I would never go back if I had the choice.").

Csak azért, mert a megoldás 90-es éveket idéz, attól még lehet jó, nem?

Használtam Gerritet, valamilyen szinten konfiguráltam is/karbantartottam is.

Egy kérdésem van: alkalmas-e olyan esetekben, amikor
- ugyanazon a projekten >1000 ember dolgozik
- mindenkinek lehet vétó joga (kb.)
- a kommittal, kóddal szorosan összefügg a review, esetenként gyors választ igényel
- napi száz/ezer módosítási javaslat érkezik, ebből szűrni kell a téged érdeklőt (és a beküldő nem feltétlen tudja, hogy téged az érdekel, hogy meghívjon review-ra). Emellett az érdeklődési köröd nincs kőbe vésve.
- van olyan, hogy egy fejlesztő csak egy patch-et akar beküldeni, aztán viszlát (nem akar regisztrálni, stb...)

Szóval megpróbáltam elképzelni a kernelfejlesztést úgy, hogy gerritet használnak review-ra, beküldésre, és az a benyomásom, hogy erre a fejlesztési modellre nem túl alkalmas. Szabad ellenkezni. De ne az legyen az érv, hogy elavult. Legyen az, hogy egy más módszerrel lehet-e ugyanezt a modellt alkalmazni, ha nem, akkor mit veszítenek és mit nyernek.

Az Android projekt kimeríti amit írtál követelménynek, csak egy picit több kód van benne (400+ repó, amiből a kernel csak 1), tehát igen, a Gerrit képes lenne kezelni. Elvileg van is olyan szervezet (Linux Foundation), akik üzemeltethetnék.

Az ok, ami miatt nem váltanak, nem technikai jellegű szerintem.

" He noted that Google, which promotes Gerrit for use with the Android project, does not use it for any of its internal projects. Even with Android, Gerrit is not really needed; Greg pointed out that, in the complicated flow chart showing how to get a patch into Android, Gerrit has a small and replaceable role. "

Amennyire én tudom, az android, bár opensource, alapvetően egy in house developed cucc, nem biztos, hogy érdemes összehasonlítani azzal a workflowval, amit a kernel csinál. Meg az is jó, hogy benne van a kernel, mint egy repo, de azért azt ugye látjuk, hogy messze nem úgy viselkedik benne, mint ahogy az lkml-esek csinálják.

Félre ne érts, fogalmam sincs, hogy valóban az-e a legjobb, amit csinálnak (minimum gyanús, hogy a fő maintanerek már körberakták az emailt maguknak, és nincs kedvük máshoz, illetve látszik az is pl a fent linkelt vicces csörtéből, hogy Andrew nem feltétlen jól itéli meg a barriert a többieknek), vagy mondom, hogy a gerrit nem jó rá, de speciel szerintem itt a benne levő kódméret, vagy hogy hány repo, az kevésbé érdekes.

Megmondom öszintén, hogy még nem volt erőm megnézni ezt a videót. Ugyanebből a sorozatból néztem meg Jonathan Corbet Kernel Reportját, és baromi elszomorító volt, amiket sikerként elkönyvelve mondott, pl. "néhány OEM-nek már túl lassan halad a kernelfejlesztés, mert nem tudnak elég gyorsan bekerülni a feature-ök" vagy mi volt az egyik -- ami nyilván totális félreértése a problémának.

Egyébként ugyanezt írtam én is, hogy itt nem technikai okok vannak a háttérben.

( szs v | 2016. 11. 07., h – 18:38 )

amikor azt mondja "ám", akkor meg kell inni egy felest

( szg0000 | 2016. 11. 08., k – 08:31 )

A kernel bugzillával együtt kéne kezelni.
Akkor egyből látni lehetne, hogy melyik commit melyik bug-hoz tartozik. Elég nevetséges, hogy külön hozzászólásban van közölve a kernel commit hash, amire git-el még külön rá kell keresni, hogy előjöjjön a diff...

____________________________________
Ha vita van, számoljanak órajelciklusokat. Egyesével.

Kib.szottul felesleges az egesz annak fenyeben, hogy a GitHubon vannak. A PR-okban visszakovetheto lenne az egesz... de hat persze a rigorozus szabalyok.

Es az a vicces, hogy maga a GitHub workflow baromira nem GitHub specifikus mar, ott van a GitLab es a Gitorious pl., ami majdnem teljes mertekben lefedi ezeket, raadasul on-premise is telepithetoek free.
--
Blog | @hron84
Üzemeltető macik

( pink v | 2016. 11. 08., k – 13:45 )

Az élet gyakran azt igazolja, hogy az ősi fapados rendszerek túlélik a fancy megoldásokat.
A probléma alapvető forrása legtöbbször az emberi trehányság, lustaság, nemtörődömség.

Jelen konkrét esetben nem foglalnék állást, pusztán megállapítom, hogy sokszor megy a nagy hűhó semmiért.