Linus a "Pató Pál urazásról"

Címkék

Linus a hétvégén bezárta a 6.1-es kernel beolvasztási időablakát (merge window) és nem átallott megmosni néhány Pató Pál úr fejét. Linus a feladatukat (pull request-ek időben való elküldését) rendszerint az legutolsó pillanatra hagyó fejlesztőkhöz intézett hétvégi levelében néhány keresetlen szót. Véleménye szerint ezt az attitűdöt a középiskola végére illene az embernek kinőnie:

Talking about frustration, let me just say that after I got my machine sorted out and caught up with the merge window, I wass somewhat frustrated with various late pull requests. I've mentioned this before, but it's _really_ quite annoying to get quite a few pull requests in the last few days of the merge window.

Yes, the merge window is two weeks, but that's very much to allow me time to look things over, not "two weeks to hurriedly put together a branch that you send Linus on Friday of the second week". The whole "do an all-nighter to get the paper in the day before the dealine" is something that should have gone out the window after highschool. Not for kernel development.

The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window. With some slack for "life happens", of course, but I really get the feeling that a few people treat the end of the merge window as a deadline, missing the whole "it was supposed to be ready before the merge window".

You know who you are.

Részletek Linus 6.1-rc1 prepatchet bejelentő levelében.

Hozzászólások

A végén leírja mi a gond, az előtte lévő rész inkább csak félreviszi a dolgot. Nem az a baj, hogy a deadline határideje előtt de utolsó pillanatban küldik be, hanem az, hogy a merge window végét tekintik deadline-nak nem az elejét, ahogy a szabályok szerint van. Ezt kellen hangsúlyozni csak, hogy az a pull request van benne a köv releaseben, ami a merge window elejéig odaér. Ettől eltérés csak nagyon kivételes esetben, de általában ami közben jön az már köv release.

Most akkor mi van?
Beküldték határidőre vagy sem?

Nem igazán követem aktívan a Linux kernel fejlesztését (nem nem vagyok benne érintette), jóformán csak annyira, amennyire itt a fórum témákat és hozzászóklásokat olvasva sikerül minimálisan belelátni.

Bennem felmerül a kérdés, hogy ezt egyáltalán miért kell leírni? Ha a merge window előtti utolsó nap a beküldési határidő, akkor ami azután érkezik, az automatikusan a következő beküldési ablak része lesz és kész. Nem tudom miért érzi feladatának behúzni azokat a fejlesztéseket, amik szerinte késve érkeztek be. Simán ott kell hagyni a következő ilyen időszakig.

Aztán ha valaki szóvá teszi, hogy miért nincs benne a legújabb kiadásban a last minute, határidő után, a merge window alatt beadott munkája, akkor tárgyilagosan lehetne közölni, hogy sajnos határidő után érkezett, csak a következőben lesz benne.

Nem, ez nem definiált. A hivatalos leírás szerint a merge window megnyitása után küldik be a maintainerek a patcheket. Az nem definiált, hogy meddig - azaz értelemszerűen a merge window végéig küldhetnek be a hivatalos leírás szerint.

Ez Linusnak nem tetszik, ezért hisztizik. Pedig csak a folyamaton kéne módosítania, mert szar, aluldefiniált a folyamat.

Ez Linusnak nem tetszik, ezért hisztizik. Pedig csak a folyamaton kéne módosítania, mert szar, aluldefiniált a folyamat.

Ez kizárt, lentebb még valami olyasmi volt, hogy Linus az elit projektmenedzser, a sok jobbágy meg kussoljon.

  1. Linus eredményeit nem elvitatva, ez egy basic folyamatmenedzsment probléma, amire elég egyszerű megoldások vannak
     
  2. Nem értem, miért kell úgy beszélni az arcról, mintha valami L Ron Hubbard reinkarnáció lenne, aki teljesen mindegy, hogy projektet vezet, kódot ír, bolfozik, stb., az úgy , és kész, mert sosem téved.

Teljesen felesleges erről beszélni. Hozza előbbre pár nappal a merge window-t. Problem solved.

Gábriel Ákos

Szeretem, mikor agile coachként oszt mindenkit. Kivételes itt nincs igaza. A merge window attól window, hogy elejétől a végéig tart, tehát ha legutolsó napon küldik be, az is épp olyan időben van, mintha az első napon. Ha ez zavarja, akkor ennek az utolsó napja után toldjon be egy feldolgozási időszakot, amikor átnézi mi érkezett be, de a fejlesztést még nem kezdik meg az RC-kkel.

Ha meg mindenki kapkod, és első nap küldik be, akkor meg az lenne a baja, hogy sok szar érkezett be, nincs rendesen megcsinálva.

The world runs on Excel spreadsheets. (Dylan Beattie)

Érdekes, én pontosan értem, hogy miről beszél és mitől kibaszott frusztrált. Egyébként, teljesen mindegy, hogy hol van a határidő. Egyetlen kulcsmondata volt a mondandójának (nem az, amit fentebb citáltak):

The whole "do an all-nighter to get the paper in the day before the dealine" is something that should have gone out the window after highschool.

Ez ^^^

trey @ gépház

Én is pontosan értem, és ezért is látom, hogy miért nincs igaza. A határidő is olyan, hogy jogos az utolsó napon beküldeni. Nem csak középiskolában, és nem csak hanyagságból. Igen, van, aki lustaságból halogatja a határidő utolsó napjáig, de vannak olyanok is, akik meg megcsinálják előbb, de kihasználják a határidőt, többször átnézik, és csak a legutolsó napon adják be. Cégeknél elég jellemző, hogy pályázatokat is utolsó nap nyújtják be, előtte többször átnézik, nehogy elsietés miatt vissza legyen dobva, kihasználják az időt, ami van rá. Ügyvédek fellebbezéssel is így szoktak lenni, inkább legyen átnézve, meg minden pont, bizonyíték felhozva benne, mint hogy el legyen szarva, és amiatt visszadobják, eljárást elnyújtsa, stb..

The world runs on Excel spreadsheets. (Dylan Beattie)

Elhiszem egyébként, hogy ez őt zavarja, és ő a főnök, de akkor oldja meg szervezéssel, határidő-módosítással. Vagy toldjon be a merge window és az első RC közé egy extra hetet, amikor már semmit nem lehet beküldeni, de neki lesz ideje a legutolsó napon beküldötteket is átnézni, vagy a merge window legyen lerövidítve egy olyan határidővel, hogy ha mindenki az utolsó napon küldi be, akkor is végezni lehessen vele.

E-mailt hiába küldözget, továbbra is mindenki a legutolsó napon fogja beküldeni. Emberi természet egyébként is. Ezzel előre kell kalkulálni. Nem csak Pató Pál esetében. Azt se tudom elfogadni, hogy ő még régi generáció. Tudomásul kell vennie, hogy aki aktívan kódol, az meg tipikusan ma már egy újabb generáció nála, meg Usákiában és úgy globálisan másmilyen hozzáállása van az embereknek, mint amihez ő szokott a finneknél, svédeknél. Mostanra megszokhatta volna, hogy nemzetközi projektet visz, és ezzel adminisztrálási gondok is vannak, nem megy minden simán, az ő kedve szerint.

The world runs on Excel spreadsheets. (Dylan Beattie)

Mondod ezt annak, aki megírta a világ számára az azóta de-facto git menedzsment eszközt :D

Ezek elvek. Egyébkén, teljesen mindegy milyen eszközt használsz, a tróger az tróger marad. Sok milliós ticketing rendszer mellett is látok olyat, akit nem érdekelnek a határidők, a figyelmeztető üzenetek, az SLA-k és semmi olyasmi, ami határok közé próbálná szorítani. Ez emberi kérdés, jellembeli, nem lehet technikai eszközökkel a jellembeli hiányosságokat kiküszöbölni.

trey @ gépház

A "projektmenedzsment technika" meg veletlenul se technologia kerdese. Tok mindegy, hogy valami elosztott szuperszamitogeppek, papirral, papirusszal vagy kotablaval felugyeled, vezeted es koveted a projektedet. Ha nem tudsz egy rendes szervezeti strukturat letrehozni, mukodesi mechanizmusok alapjait letenni, amelyek alkalmazkodnak az adott kulturahoz (es valamelyest formaljak azt), akkor nem biztos, hogy a megfelelo ember vagy a poszton.

A projekt bedoleseert pedig a vezetot terheli a felelosseg, nem a beosztottat. Persze mindig az udvaros Jozsi a felelos, mert hat rosszul seperte fel a lehullott leveleket.

Nagyszerű elmélet, csak itt nem munkahelyi beosztott-vezető viszony van. A munkahelyi viszonyban kötelességek vannak, amit számon lehet kérni, amelyek nem teljesítése esetén retorziót lehet alkalmazni (figyelmeztetés, fegyelmi, prémium- és bérmegvonás stb.)

Egy open source projektnél ezt hogy képzelted el? Milyen eszközök vannak Linus kezében?

trey @ gépház

Itt nem is veled beszélgettem, hanem kubivel. Érdemes lenne szálban olvasni ... Erre vártam volna választ:

Nagyszerű elmélet, csak itt nem munkahelyi beosztott-vezető viszony van. A munkahelyi viszonyban kötelességek vannak, amit számon lehet kérni, amelyek nem teljesítése esetén retorziót lehet alkalmazni (figyelmeztetés, fegyelmi, prémium- és bérmegvonás stb.)

Egy open source projektnél ezt hogy képzelted el? Milyen eszközök vannak Linus kezében?

trey @ gépház

Én nem is azt állítottam, hogy projektmenedzsment eszköz (kifejetetten ügyeltem rá, hogy ne legyen benne a "projekt" szó, ismerve az itteni balfaszokat), azt már te költötted hozzá. Arra céloztam, hogy (aki egy ilyen eszközt és egyébként mást is) megír a saját igényeire 0-ról, az nem szorul arra, hogy kioktassák az internet fotelbölcsei.

trey @ gépház

aki megírta a világ számára az azóta de-facto git menedzsment eszközt

Azt most írtam bele, mert amúgy projektmenedzsmentből indult a disputa, szóval továbbra is téged oktatlak ki, hogy a Git nem egy menedzsment eszköz.

megír a saját igényeire 0-ról, az nem szorul arra, hogy kioktassák az internet fotelbölcsei

Ezt most úgy írod, mintha eddig senkit nem oktattál volna ki fotelbölcsként, aki letett valamit az asztalra... :D

szóval továbbra is téged oktatlak ki, hogy a Git nem egy menedzsment eszköz

Úgy látszik ez mellett elmentem szó nélkül. Dehogynem bazmeg. A git egy verziókezelő / forráskód-menedzsment eszköz. Remélem a Google kisegít ebben, ha más nem is.

trey @ gépház

Innen indultunk: "Regi vagasu embernek tobb projektmenedzsment technika kene, hogy a birtokaban legyen."

Ez abban a 95 százalékban volt, amit nem olvasol el tőlem, de nem is én írtam. Az meg ugye külön szép, hogy utólag kicsit átírod a hozzászólásod... :D

Ha a git a forráskódmenedzsment eszköz,

Kérlek ne vitatkozzunk olyasmiről, ami nyilvánvaló. 

miért nem azt használják beolvasztáskor, miért e-mailben kell neki patcheket küldeni?

A levelet Linusnak kell címezned.

Ezek szerint Linus a saját maga által írt forráskódmenedzsment-eszközt nem használja a kernel kódjának menedzselésére.

Nem ez volt a mondandóm lényege. Hanem az, hogy ha Torvalds meg tudott írni egy git-szintű eszközt a saját igényeire, valamit írt búvárkodáshoz egy saját szoftvert, mert ami a "piacon" volt, egy rakás szar volt, valamit írt egy kernelt, mert szüksége volt rá, akkor feltételezhetjük, hogy van olyan tudás, skill a birtokában és rendszer a fejében, amivel a Linux projektmenedzsmentjét is le tudja vezényelni.

Most komolyan ennyire ostobának nézitek? Most tényleg ti akarjátok megmondani neki 30 évvel a háta mögött, hogy hogyan kell a világ legnagyobb közösségi szoftverfejlesztési projektjét igazgatni és menedzselni?

Nem lenne ez a kabát kicsit nagy rátok?!

trey @ gépház

írt egy kernelt, mert szüksége volt rá, akkor feltételezhetjük, hogy van olyan tudás, skill a birtokában és rendszer a fejében, amivel a Linux projektmenedzsmentjét is le tudja vezényelni

- mondta a $random multi középvezetője, és kinevezte a senior fejlesztőt teamleadnek, hiszen mi baj lehet belőle. :)

Torvalds szerintem minimum egy évtizede nem senior fejlesztője a Linux kernelnek és szerintem te ezzel pontosan tisztában vagy. Nem egy interjúban nyilatkozta, hogy konkrétan nem is tudja mikor írt utoljára önmagában értelmezhető kódot.

Linus Torvalds: 'I'm not a programmer anymore'

[...]

I don't know coding at all anymore. Most of the code I write is in my e-mails. So somebody sends me a patch ... I [reply with] pseudo code. I'm so used to editing patches now I sometimes edit patches and send out the patch without having ever tested it. I literally wrote it in the mail and say, 'I think this is how it should be done,' but this is what I do, I am not a programmer.

So, Hohndel asked, "What is your job?" Torvalds replied, "I read and write a lot of email. My job really is, in the end, is to say 'no.' Somebody has to say 'no' to [this patch or that pull request]. And because developers know that if they do something that I'll say 'no' to, they do a better job of writing the code."

Torvalds continued, "Sometimes the code changes are so obvious that no messages really required, but that is very very rare." To help your code pass muster with Torvalds it helps to ''explain why the code does something and why some change is needed because that in turn helps the managerial side of the equation, where if you can explain your code to me, I will trust the code."

In short, these days Torvalds is a code manager and maintainer, not a developer. That's fine with him: "I see one of my primary goals to be very responsive when people send me patches. I want to be like, I say yes or no within a day or two. During a merge, the day or two may stretch into a week, but I want to be there all the time as a maintainer." 

[...]

Biztosan adod csak a hülyét ...

trey @ gépház

  1. A smiley azért van ott, mert nem volt teljesen komoly - még ha egy valóban létező, káros jelenségre is utaltam vele
  2. Linustól régebben olvastam interjút, mint amennyire régen ő szoftvert fejlesztett. Mint említettem, ő nem Jézus, L Ron Hubbard, stb., hogy minden megnyilatkozását elolvassam.

tl;dr szerintem az egy rossz folyamat, ahol a folyamat lépéseit szabályosan követve rendszeresen rossz lesz az eredmény

Meggyőzhető vagyok racionális érvekkel, de a főnök megmondta, hogy így jó, az nem érv. Akkor sem, a főnök egyébként jó arc, és rendszeresen fizeti a sört a karácsonyi bulikban, vagy összetákolt valami OS kernelt.

Az meggyőző érv, hogy a módszereivel és kéréseivel - ha azokat betartják - el lehet vezetni sikeresen a világ legnagyobb open source projektjét. Ez akkor is meggyőző érv, ha te személyesen nem fogadod el. Egyébként, pedig még mindig várom, hogy szerintetek hogyan lehetne a vállalatoknál megszokott eszközök hiánya mellett pont úgy vezetni egy ilyen projektet, mit ahogy mondjuk egy vállalatnál teszik.

trey @ gépház

Ne ennyire binárisan lásd, a projekt működik, Linus mégis telesírta a párnáját, hogy az emberei nem akkor küldték a PR-okat, amikor ő szerette volna. Erre normális helyen az a megoldás, hogy a határidőt oda állítjuk be, ameddig a PR-okat meg szeretnénk kapni.

Egyébként, pedig még mindig várom, hogy szerintetek hogyan lehetne a vállalatoknál megszokott eszközök hiánya mellett pont úgy vezetni egy ilyen projektet, mit ahogy mondjuk egy vállalatnál teszik.

Pontosan milyen eszköz hiányzik? A fizetés?

Ne ennyire binárisan lásd, a projekt működik, Linus mégis telesírta a párnáját, hogy az emberei nem akkor küldték a PR-okat, amikor ő szerette volna. Erre normális helyen az a megoldás, hogy a határidőt oda állítjuk be, ameddig a PR-okat meg szeretnénk kapni.

Teljesen mindegy, hogy hova állítod a határidőt, mert a notórius határidő-be-nem-tartók telibe' szarják.

Pontosan milyen eszköz hiányzik? A fizetés?

Szerintem jól felsoroltam: figyelmeztetés, fegyelmi, prémium- és bérmegvonás, lefokozás, áthelyezés, kirúgás

Semmi olyan, aminek az egyénre komolyabb következménye van. Egyetlen eszköz a kezében a nyilvános "megszégyenítés" (jajj de nem PC ez ma!!111 rikkant fel a cián hajú Z generáció) és ezzel él. Teszem hozzá, hogy ezt azért nem a Washington Post-ban feladott címoldalas hirdetésben teszi, hanem az LKML nevű underground technikai listán.

trey @ gépház

Kb en is egyetertek. Linus mindosszesen annyit szeretne elerni, hogy a merge window alatt mindenki egyenletesen legyen terhelve. Most ugye az a trauma, hogy a window elejen mindenki malmozik: o azert mert nincs mit csinalni (nincs patch a queue-ban), a karbantartok meg basznak dolgozni. A vegen meg megy a nagy teperes, hogy mindent begyurmazzanak. Gondolom egy kollaborativ fejlesztest szeretne megvalositani, ahol az emberek nem csak a torveny betujet, hanem a szellemet is ertik es betartjak. Ertsd: a karbantarto (elvileg smart guy) felfogja, hogy a rendszer hatekony mukodtetesehez jo lenne, ha nem dugitanak be az egy szem embert, aki rauti a stemplit a patch-re. Minimalis empatia es intelligencia. Szerintem nem extra elvaras, csak be kellene latni, hogy mas is kuld patchet rajtunk kivul, es hogy ez ugy hatekony, ha nem az utolso pillanatra halasztjuk…

Persze egy fasza enterprise kornyezetben ezt a hatekonysagexpertek, produktownerek es projektadminisztratorok meg tudnak szerelni, hogy egy kozepesen idomitott csimpanzt is munkara lehessen fogni, es lenne egy olyan folyamat a vege, hogy bejojozik a szemed a szervezeti diagramtol. Azt viszont bizton merem allitani, hogy a sztori vege egy olyan projekt lenne, amiben dolgozni sem jo es nem is produktiv.

Es valo igaz, Linus kezeben keves eszkoz van, hogy terelje ezeket az ugyeket. Vagy gentle reminder (ezt latjuk fent), vagy a nuklearis opcio, es elkezdi kib*aszkodni az alrendszerek karbantartoit, akik keptelenek felfogni, hogy mas is van a vilagon rajtuk kivul. Eddig igazabol gentleman volt, megha idonkent a stilusa sarkos.

Ugyanazt a mozit nézzük?

Linus mindosszesen annyit szeretne elerni, hogy a merge window alatt mindenki egyenletesen legyen terhelve. Most ugye az a trauma, hogy a window elejen mindenki malmozik: o azert mert nincs mit csinalni (nincs patch a queue-ban), a karbantartok meg basznak dolgozni. A vegen meg megy a nagy teperes, hogy mindent begyurmazzanak.

vs.

The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window.

--

ha nem dugitanak be az egy szem embert, aki rauti a stemplit a patch-re

Ez az alapvető problémája a dolognak, amin már réges-rég túl kellett volna lendülni, amikor a kernel mérete túlnőtt rajta. Lehet körbetákolni és különféle zsírokkal kenegetni a helyzetet, de az a valóság, hogy ezeket a problémákat saját maga okozza azzal, hogy megkerülhetetlené tette magát.

Szerintem ugyanazt a mozit nezzuk. Azert kellene keszen lennie a patchnek a window elejen kb, mert igy meg belefer 1-2 review kor. Tehat lehet rajta pofozni aprobb dolgokat Linus visszajelzese alapjan. Ez sokkal stresszesebb, ha a window vegen kezdenek iteralni, amikor mar semmire nincs ido.

Szerinted problema, szerintem meg ezert er messzebb a projekt annal, amikor egy picsanyi projekthez 100 comittee-t grundolnak, csak a code of conduct megirasa utan fogalmuk nincs arrol, hogy hogyan kellene dolgozni.

Szerintem az a sebesseg, amivel a kernel a patcheket abszolvalja, illetve, hogy emellett az eredmeny minosege okes, azt mutatja, hogy ez a modell mukodokepes. Namost ha valasztani kell a mukodokepesseg kockaztatasa es akozott, hogy nehany lusta diszno eszbe kapjon, en szo nelkul szavazok az utobbira.

Szerintem ugyanazt a mozit nezzuk.

Pedig mégse, ezek szerint.

Azert kellene keszen lennie a patchnek a window elejen kb, mert igy meg belefer 1-2 review kor.

Az egész bazmegelés abból jön, hogy nem a merge window open előtt jön a PR: "The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window."

Nem az a baj, hogy a merge window ideje alatt nem egyenletesen jönnek a PR-ek, hanem az, hogy közben jönnek: "should be ready *before* the merge window opens".

--

Szerintem az a sebesseg, amivel a kernel a patcheket abszolvalja, illetve, hogy emellett az eredmeny minosege okes, azt mutatja, hogy ez a modell mukodokepes.

Honnan tudod, hogy nem lenne sokkal jobb, ha az egész folyamat vége nem One Man Show lenne? 

Namost ha valasztani kell a mukodokepesseg kockaztatasa es akozott, hogy nehany lusta diszno eszbe kapjon, en szo nelkul szavazok az utobbira.

Namost, ezt úgy mondod, mintha nem lett volna elbaszva n+1 alkalommal a kernel és soha nem kellene hibát javítani, csak a feature halmazok jönnének évek óta.

Az az erzesem, hogy azzal a feltetelezessel elsz, hogy emberunk tulajdonkeppen egy “approve machine”, tehat amikor o megkap egy patchet, akkor annak csak egy kimenetele lehet, hogy asap beolvasztja. *Szerintem* nem errol van szo es erre utalt is Linus a fenti interjuban (talan trey idezte be), gyakran visszakuldi a kerest, hogy valtoztassanak rajta par dolgot. Az en velemenyem szerint ez az a pont, ahol bizonyos problemak kihullanak, illetve ahol az egesz cucc konzisztenciajat kontrollalni lehet magas szinten. Es ez szarodik el, ha egyesek keptelenek a fegyelmezett munkara. Mert nagyon rovid ido alatt kellene sok interakcionak tortennie, egy olyan kornyezetben, ahol potencialisan az emberek aktivitasi ideje nem is fedi egymast (idozona kulonbsegek + munkarend).

Nem tudom biztosra, hogyha tetszoleges aspergeres zsenire biznank a dolgot, akkor nem lenne-e jobb a dolog, lehetne merge window commitee-t alakitani es szetkurni mindent kamarillapolitikaval, es az is lehet, hogy egy code of conduct is jot tenne. Viccet felreteve van szazezer otlet, amit ki lehetne probalni, de szerintem a projektet ez a Torvalds nevu csavo vezeti, es minden joga es oka megvan ahhoz, hogy eldontse, hogy kivel akar egyutt dolgozni es milyen modon (amugy egy korabbi interjuban ezt jelolte meg az OSS modell elonyekent).

A linux kernel nem tokeletes, senki nem allitott ilyet, de a komoromisszumok, amiket meghozott eredmenyeznek egy olyan innovacios szintet, bizotnsagossagot, teljesitmenyt es nyitottsagot, ami miatt sokan tudnak vele jol dolgozni.

Amugy ez meg mar szamtalanszor elhangzott, hogy lehet menni megcsinalni a mukodokepes alternativakat, volt is jopar probalkozas, csak eppen a tobbseg azelott krepal be, mielott barmi hasznalhatot produkalna, es az a keves, amibol lesz valami az meg a niche nichenek a szerepet tolti be max (pl OpenBSD, de mondjuk nekik is van diktatoruk). Ez nem megfellebezhetetlen bizonyiteka Torvalds projektvezetesi modszerenek helyessegenek, de talan nemi osszefugges van.

Az az erzesem, hogy azzal a feltetelezessel elsz, hogy emberunk tulajdonkeppen egy “approve machine”, tehat amikor o megkap egy patchet, akkor annak csak egy kimenetele lehet, hogy asap beolvasztja.

Nem, én értelmezem azt, amit leírt, vagyis a patch PR deadline a merge window előtt van: "The rule is that things that get sent to me should be ready *before* the merge window opens, not be made ready during the merge window."

Ezzel szöges ellentétben áll az, amit írtál, ami szerint a baj az, hogy nem egyenletesen van elosztva a merge window alatt a bejövő PR halmaz: "Most ugye az a trauma, hogy a window elejen mindenki malmozik: o azert mert nincs mit csinalni (nincs patch a queue-ban), a karbantartok meg basznak dolgozni. A vegen meg megy a nagy teperes, hogy mindent begyurmazzanak."

Ezért kérdezem már harmadszor, hogy ugyanazt a mozit nézzük-e?

1. “Ready” jelentese a fentieknel azt jelenti, hogy a fejlesztoje azt gondolja rola, hogy mar nincs mit hozzatenni. 
 

2. Nyilik az ablak, bekuldi.

 

3. Linus ranez, ket kimenetel lehetseges:

 - Ok -> merge

 - Nem ok -> vissza a feladohoz, hogy szerelje meg.

 

Tehat a merge window elejen a fejleszto gondolja azt, hogy “ready”, az orakulum (Linus) velemenyet meg nem tudjuk (nem is tudhatjuk, mert meg nem latta). A merge window arra szolgal, hogy az orakulum velemenye is az legyen, hogy “ready”.

Ez az en interpretaciom a fent leirtakhoz. 
 

Nyilvan egy halom embernek az a percepcioja a kernelfejleszteshez, hogy be akarja tolni a kovetkezo cuccosat asap, escezt ugy csinalja, hogy kinezi, hogy mi a kovetkezo release datum, es a hozza tartozo merge window veget megcelozva probal valamit osszehaxolni. A torveny betujet ezzel nem serti, de en is probalnam a project lead helyeben a gyakorlatot megszuntetni.

Hasonlo pelda pl. a kozlekedesbol, hogy vannak olyan helyzetek, ahol a kolcsonos udvariassag dont egy helyzetrol. Ez azt jelenti, hogy lemondok a lehetosegemrol, hogy a rendszer hatekonyan mukodhessen. Persze allhatunk naphosszatva keresztezodesben azt hajtogatva, hogy nekunk jogunk van nem elozekenynek lenni…

Linus reszerol enny volt a keres lenyege. Az en velemenyem szerint kicsit ciki, hogy ennek el kellett hangzania es nagyon ciki, hogy az emberek ezutan sem belatoak.

"Ez az en interpretaciom a fent leirtakhoz. "

Látod, pont ez a baj, hogy léteznek különféle interpretációk egy elvileg egyértelmű folyamathoz. Ha nincs expliciten leírva, hogy mi a folyamat, akkor születik ez, hogy a különféle emberek különféleképpen interpretálják a dolgokat, és amikor valamelyiküknek ez nem tetszik, hisztizni kezd, ahelyett, hogy egyértelműsítené a folyamatleírást, hogy ne legyenek különböző interpretációk.

Linus fogalmazhatott volna sokkal profibban is: "Kedves maintainerek, a hatékony kernelfejlesztés érdekében az a folyamat, hogy:"

De nem, nekiállt hisztizni.

Ha ez lett volna az elso “hiszti” (szerintem meg ez is a gentle reminder szintjen mozgott), meg talan meg is ertenem. Viszont jelen esetben ez visszakovethetoen nem az elso es nem a masodik alkalom. Ti nem kaptatok meg a memot ;)?

Tovabba nekem az a teoriam, hogy a szoftverfejlesztes es azon belul a kernelfejlesztes az a terulet, ahol meg nem kell jogaszkodva fogalmazni, illetve kepekkel is elmagyarazni, hogy ne tegyuk a macskatva mikroba. Persze lehet, hogy mar en is tul oreg vagyok ehhez.

Illetve szivunkre teve a kezunket, ha a ket verzio kozul kell valasztani, hogy lustasagbol(szandekosan) vagy hulyesegbol(akaratlanul) volt ez az egesz felreertelmezve, szerintem egyertelmu a dolog. Dehat megintcsak en vagyok tul oreg es megkeseredett ;).

Ez az en interpretaciom a fent leirtakhoz. 

Igen, én értem, hogy van egy interpretációd a leírtakhoz, csak az nem fedi a leírtakat: "things that get sent to me should be ready *before* the merge window opens"

Nyilik az ablak, bekuldi.

Nem, a PR ott kell legyen, amint nyílik a merge window: "should be ready *before* the merge window opens"

“Ready” jelentese a fentieknel azt jelenti, hogy a fejlesztoje azt gondolja rola, hogy mar nincs mit hozzatenni. 

A ready jelentése az, hogy van PR: "a few people treat the end of the merge window as a deadline, missing the whole "it was supposed to be ready before the merge window"."

Melyik szó nem érthető abból, hogy "before the merge window"?

Az en velemenyem szerint kicsit ciki, hogy ennek el kellett hangzania es nagyon ciki, hogy az emberek ezutan sem belatoak.

Baszod, az általad eddig leírtak alapján, ha kernelfejlesztő lennél, akkor pont kurvára beszólna neked is Linus azért, mert a merge window open időpontot követően küldenél be PR-t... :D

A ready jelentése az, hogy van PR
 

Sehol nincs ez leirva, de ok, fogadjuk el a te interpretaciodat *is* validnak. Csak akkor azt nem ertem, hogy a latszolag preciz Linus miert nem bassza ki teljesen a window kozepen erkezo patcheket. A te interpretaciod alapjan egy masodik napon erkezo patch is blaszfemia, ellenben Linus panaszkodas nelkul beolvasztja (ha a kontent megfelelo).

Nekem ebbol az jon le, hogy nem a te interpretaciod a valoszinuleg helyes, mert a project lead cselekedetei nem ezt az interpretaciot tukrozik. Ellenben az en ertelmezesem fedi az ugyet. 
 

Es most meg poroghetsz tovabb, kiragadott felmondatok szemantikajan, meg hogy mi mennyire felreertheto, de az extra kontextus, ami a hozzaferheto, szerintem egyertelmuve teszi az ugyet. Innentol kezdve beleragadhatunk a jogaszkodasba meg a nyelvtannaciskodasba, de nem latom, hogy mennyivel erunk elorebb. Max annyi johet ki belole, hogy szemelyesen te nem vagy kepes ertelmezni es felfogni, hogy mit akar Linus a maintainerektol. De ez meg nem feltetlen nagy problema (nekem egeszen biztosan), gondolom te sem forgolodsz majd almatlanul, es Linus is tuleli.
 

a latszolag preciz Linus miert nem bassza ki teljesen a window kozepen erkezo patcheket

Ahogy írja is erről: "With some slack for "life happens", of course [...]"

Nekem ebbol az jon le, hogy nem a te interpretaciod a valoszinuleg helyes, mert a project lead cselekedetei nem ezt az interpretaciot tukrozik. Ellenben az en ertelmezesem fedi az ugyet. 

Nagyon jó, tehát akkor ugyanarról a folyamatról van két szögesen eltérő értelmezésünk, egymásnak ellentmondó leírt szabályokkal és a project lead viselkedése sem kiszámítható? Ez a sikeres projektmenedzsment receptje.

A te interpretaciod alapjan egy masodik napon erkezo patch is blaszfemia, ellenben Linus panaszkodas nelkul beolvasztja (ha a kontent megfelelo).

Ja, figyelj, nem lehet, hogy egy többféleképp értelmezhető szabály értelmezése körül van az egész baszkolódás kiinduló pontja, ahol ezen felül van n+1 rendhagyó kivétel a folyamat során, plusz az informális és szubjektív 'nem lehetne-e, hogy"? Áh, lófaszt folyamat során, a kialakult szokás során.

--

Például így néz ki egy roadmap dátumozása:

	September 15	5.3 stable release, merge window opens
	September 30	5.4-rc1, merge window closes
	October 6	5.4-rc2
	October 13	5.4-rc3
	October 20	5.4-rc4
	October 27	5.4-rc5
	November 3	5.4-rc6
	November 10	5.4-rc7
	November 17	5.4-rc8
	November 24	5.4 stable release

Lásd az értelmezésed a témáról, mintha a merge window szolgálna arra, hogy kész legyen a stable release: "Azert kellene keszen lennie a patchnek a window elejen kb, mert igy meg belefer 1-2 review kor. Tehat lehet rajta pofozni aprobb dolgokat Linus visszajelzese alapjan. Ez sokkal stresszesebb, ha a window vegen kezdenek iteralni, amikor mar semmire nincs ido."

Kurva sok idő van még apróbb dolgokat pofozni, arra vannak az -rc körök, tehát újra: "things that get sent to me should be ready *before* the merge window opens".

Max annyi johet ki belole, hogy szemelyesen te nem vagy kepes ertelmezni es felfogni, hogy mit akar Linus a maintainerektol.

Miért, te képes vagy értelmezni? Mert innen nézve van egy külön bejáratú interpretációd a helyzetről, amire azt próbálod ráfeszíteni, hogy bizony ez történt a valóságban és mindenki más hülye.

Vagy tartsa be a meglévő szabályokat, amelyeket leírtak, vagy legyen egyértelmű, hogy más szabályokat szeretne, és/vagy ne játssza a sértődöttet, mert bepusztult a memória a gépében és ez miatt egy hét késésben van. Faszé' nincs egy tesztfarmja és a faszé' saját gépén kell experimental kernellel dolgoznia, satöbbi.

Igen, ideadtál egy ábrát, amin van két hét merge window. Amit Linus review windownak képzel, de akkor vagy csinálja azt, hogy merge windowot review windownak hívja és a review window t=0 időpillanatában lezárja a PR-ek fogadását, vagy ami akkor jön, már csak a következő verzióba kerül bele, vagy bánomisén. Fura módon ilyen és ehhez hasonló problémákat cégek ezrei képesek megugrani különösebb picsogás nélkül, csak őfelségének nem megy.

Leírtam egy problémát, amivel kapcsolatban Linus már 14 évvel ezelőtt is fejeket mosott. Most ugyanazok, 14 évvel később, még mindig nem értik, hogy a főnök mit kér. Az ilyen beosztott vagy

  • értelmi fogyatékos és/vagy
  • hanyag és/vagy
  • troll

ember. A többi meg csak kifogás.

trey @ gépház

Tehát 14 év alatt nem jött rá a főni, hogy szar a process?

Egyébként ahogy elnézem, Linus a Linux Foundation alkalmazottja, David S. Miller meg a RedHat-é. Amennyire tudom, a Red Hatot nem birtokolja a Linux Foundation, szóval nem igazán tekinthető Linus alkalmazottjának...

Itt ket nezet utkozik: van az az allaspont, amit legtobb enterprise kozeg kovet, hogy szenne szabalyozzuk a folyamatot, hogy akarva se lehessen szetkurni. Ezt meg lehet tenni, cserebe a folyamat (es igy az innovacio) lassabb lesz. Nem baj, ok ezzel egyuttelnek, az o intezmenyi celjaiknak ez jobban megfelel.

A linux kernel fejlesztesi modellje elvileg lehetoseget ad a gyorsabb tempora, de ez feltetelezi a “kooperativ” szereplok reszvetelet, akik kepesek atlatni a folyamat egeszet es nem csak lokalisan optimalizalni (jovanazugyazutolsonapon, majd legfeljebb az approver nem alszik ket napig miattunk).

Es hat vitathatlanul nem rossz ez az egesz, a szabalyokat betartva valoszinuleg annyi ido alatt be lehet tolni erdemi  valtoztatasokat a kernelbe, hogy anny ido alatt az enterprise vilagban egy sor kod nem irodna, csak valami fogalmatlan PO keresne, hogy melyik koltseghelyre lehetne majd bekonyvelni a leendo fejleszteshez szukseges penzt…

A folyamatok szénné szabályozása egy dolog miatt van: nem egy embertől függnek a dolgok, "villamoskompatibilis". Ha Linus holnap meghal, mi fog történni a kernellel?

 

Ajánlok egy jó cikket, már nagyon régi, de nagyon jó: https://www.fastcompany.com/28121/they-write-right-stuff

 

A lényeg a folyamat, ha bármi gebasz van, akkor a folyamat nem jó, a folyamatban van hiba és nem az emberben.

 

How do they write the right stuff?

The answer is, it’s the process. The group’s most important creation is not the perfect software they write — it’s the process they invented that writes the perfect software.

 

Don’t just fix the mistakes — fix whatever permitted the mistake in the first place.

The process is so pervasive, it gets the blame for any error — if there is a flaw in the software, there must be something wrong with the way its being written, something that can be corrected. Any error not found at the planning stage has slipped through at least some checks. Why? Is there something wrong with the inspection process? Does a question need to be added to a checklist?

Importantly, the group avoids blaming people for errors. The process assumes blame – and it’s the process that is analyzed to discover why and how an error got through. 

Dolgoztam jopar multinal, csinalnak rengeteg dolgot villamoskompatibilitas urugyen, es bizton allithatom, hogy egyik projekt sem tunt villamoskompatibilisebbnek, mint a kernel.

Konnyu fikazni a linuxot, mert oriasi transzparencia mellett fejlesztik. Nem csak a forraskod publikus, hanem a statikus es dinamikus kodanalizis eredmenyei es a fejlesztoi kommunikacio jelentos resze is. Egy enterprise kozegben fejlesztett cucc ezt hetpecsetes titokkent kezeli, nem veletlenul. A marketingdepartment majd jol megmondja, hogy ezt a vilag legjobb mernokei csinaltak es innovativ es top-class es a legmodernebb projektmenedzsment modszerekkel dolgoztak… En meg asitok es fanyar mosollyal tovabblapozok. 

Igen, az is elgondolkodtató, hogy amikor valakik hetvenkednek hogy ők ilyen meg olyan technológiát használnak és ennyire meg annyira jó, vagy amikor fordítva éppenséggel panaszkodnak, akkor az mind vélhetően NDA alatt lett volna. Ezért panaszkodni nem kéne, a hetvenkedést meg nyugodtan lehet kétkedve fogadni, bizonyítani úgysem lehet :-P

Jaja, emlekszem, amikor a perzsa kiraly megkorbacsoltatta a tengert, mert a hadiflotta megsemmisult a viharban. Szupi, senki nem vitte el a balhet. Ez igy csak egy nagyon szep megfogalmazasa a felelosseg haritasanak. 
 

A szoftverfejlesztesnek resze a processz is, meg a fejleszto is, es barmelyik lehet kinosan nem oda illo. Kijelolhatjuk barmelyiket szent tehenkent, es ugyanakkora hibat kovetunk el. Vagy a processz a szent tehen es kioljuk a kreativitast es a flexibilitast es a munkavallalok menekulnek. Vagy az ember a szent tehen, viszont igy elofordul, hogy alkalmatlanok kore epitunk csapatot, amelyik nem kepes eredmenyeket produkalni, csak a processzt csiszolgatni. En az en csapatom vezeteseben egyik szelsoseggel sem vagyok hajlando azonosulni. A komplikalt esetekben hozok olyan dontest, aminek a forrasa lehet tapasztalati, intuitiv vagy eppen tenyalapu. A hibas donteseket felvallalom es probalok tanulni belole. A vegen meg a management es a csapatom eldonti, hogy jol vegzem-e a munkamat vagy nem. Nincs szuksegem egy kinevezett szalmababra, akire a hibaimat lehet fogni.

A modern internethasználók egyik nagy problémája, hogy túl sok pszichológiai szakkifejezést ismernek, amelyekkel aztán vakon és süketen tudnak egymásra lövöldözni. :-)

Szerény meglátásom szerint a "régi vágású" ebben a szövegkörnyezetben mindössze annyit jelent, hogy nevezett feltételez a többiekről egy bizonyos korrekt hozzáállást.

Ami néha nem jön be...

Na de azért ettől nem ő a nárcisztikus, hanem a többi az inkorrekt.

Értem, amit mondasz, de azért nem minden esetben ugyanazt jelenti a patópálozás. Hasonlítsuk össze a kernel fejlesztők és az adóbevallók esetében.

Kernel: a határidő ezek szerint csak egy irányadó valami. Adóbevallás: a határidő egy fix fogalom.

Kernel: semmi súlyos következménye nincs a határidőről lemaradásnak. Adóbevallás: bünti lesz belőle.

Kernel: a fogadó fél picsog. Adóbevallás: a beküldő fél picsog.

Annyi a közös a kettőben, hogy aki az utolsó pillanatra vár, az megszívhatja, és akkor kussoljon.

Van egy remek megoldási javaslatom: időpontfoglalás a 2 hetes merge window-ban. A ciklus előtt a fejlesztők lefoglalhatnak limitált számú időpontot, amikor beküldhetik a patch-et. Ha lekésik, akkor csak a következő ciklusra kapnak újabb időpontot. Linus így előre látná a két hét beosztását, és a péntek esti időpontok már az elején elfogynának. (Vicc.)

ebbol is latszik, hogy az osszes kernelfejleszto magyar, lasd a vers veget.

Szerkesztve: 2022. 10. 17., h – 13:59

Először is, definiálja Linus egyértelműen, hogy mi a merge window. Az az időszak, amikor PR-ok beküldhetők, vagy az, amikor ő átnézi őket? Mert nekem az jön le a levélből, hogy nem egyértelmű ez a kernelfejlesztők számára, és Linus máshogy értelmezi, mint ők.

Nem azzal van gond, hogy #lustafejlesztők, hanem azzal, hogy mást jelent nekik a merge window, mint Linusnak. Nekik a PR beküldhetőségi idejét (pl. a 6.1-hez a merge window azt jelenti nekik, hogy ez idő alatt beküldhető a 6.1-hez bármi, bármikor, az utolsó másodpercben is), míg Linusnak azt jelenti, hogy ő ennyi időt ad magának a merge window előtt beérkezett PR-ekre, hogy mergelje.

Nagyon egyszerű a megoldás: kell egy PR window is: az az időszak, amíg beküldhetők PR-ek. A merge window alatt Linus csak ezzel foglalkozik. A két időszak nem átlapolódó, a merge window szigorúan követi a PR window-t.

És így mindenkinek egyértelmű, hogy a fejlesztési szakasz melyik pontján mit kell és mit lehet csinálnia.

 

De hát ez ilyen, ha bazárelven akarnak komoly projektet menedzselni, azt nem lehet egy idő után szigorú szabályok nélkül csinálni. A létező informális szabályok pedig nem elegendőek, mert nem egyértelműek. Formálissá kell tenni, és kész. Innentől kezdve a PR beküldő és Linus is hivatkozhat a szabályra, és nem kell ilyen leveleket írnia, hogy "hülyék vagytok". Nem, nem hülyék és nem lusták, csak nem egyértelműek a játékszabályok a szereplők számára.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree…

Itt egyértelműen szerepel, hogy merge window megnyitása után bármikor beküldhető patch.

When the merge window opens, top-level maintainers will ask Linus to "pull"
the patches they have selected for merging from their repositories.  If
Linus agrees, the stream of patches will flow up into his repository,
becoming part of the mainline kernel.  The amount of attention that Linus
pays to specific patches received in a pull operation varies.  It is clear
that, sometimes, he looks quite closely.  But, as a general rule, Linus
trusts the subsystem maintainers to not send bad patches upstream.

El is hinném ezt a szép terelést, ha Linus a merge window alatt a világ összes fejlesztőjétől fogadna el PR-t, nem csak egy maroknyi karbantartótól, akikkel évek óta küzd, akik pontosan tudják a szokásait és rigolyáit (még én is tudom, aki csak a leveleit olvasom). Mindegyik pontosan tudja, hogy mi a gyakorlat. Erre is utal:

You know who you are.

trey @ gépház

Ezzel nem erre utal. Ennek a magyar fordítása az: Mindenki tudja, kire gondolok.

Nem akarja néven nevezni őket, de mindenki tudja, hogy kire gondol.

És semmi terelés nincs ebben.

Ha a maintainerek számára nem egyértelmű a helyzet, akkor tegye egyértelművé. Ha ennyire zavarja ez, dobja vissza a patchet és kész, nem kell vele szarakodni. Megmondja, hogy bocsika, időn túl érkezett, kuka. Majd következő körben jöhet. De nem ezt tette. Miért nem?

Ha a maintainerek számára nem egyértelmű a helyzet,

Ha a maintainer-el számára nem egyértelmű a helyzet (kétlem), akkor kérdezzenek. Történt ilyen? Kértek felvilágosítást? Nem. Ha nem és ennek ellenére folytatják azt, ami miatt Linus többször kérte őket, hogy ne tegyék, azt nem tudom másnak venni, mint nemtörődömségnek, hanyagságnak.

Ezer éve megy ez a sztori. Persze, van, akinek új:

https://yarchive.net/comp/linux/merge_window.html

trey @ gépház

Ezzel még mindig az a baj, hogy ez a dolog (túlhajtottság) bárhol létező dolog. Nem csak a linux kernel esetén. Enterprise szektorban is így van.

Ezért szokott lenni beküldési határidő, majd ha ez elérezett akkor utána van a befogadási periódus. Sok helyen sürgős változásokat még ilyenkor is befogadnak. Így működik ez. Majd rájön, nem hülye gyerek a Linus.  

Úgy érzem a kommenteket olvasva, hogy egy dolog felett mindenki elsiklik...

 

Simán mondhatja Linus, hogy a Merge Window megnyitása után érkezett PR-okat nem húzza be csak következő release-be, viszont ahogy ő is írja van egy kivételes eset, amikor mégis szükséges kései PR-t behúzni, amikor olyan javítás érkezik, ami súlyos hibát javítana. Viszont többen is a sima kis feature PR-t is úgy küldik be, hogy az sürgősen kell még adott merge window-ban, mert vagy villogni akar vele, vagy csak ő maga használni szeretné és minél hamarabb végig akarja verni mindenkin a dolgot.

 

Linus-nak az ilyen esetekben át kell néznie, hogy adott PR mit is csinál, mit is javít, vagy átdobható következő release-re. Ha egy tucat fejlesztő utolsó pillanatban dobja be ezeket, akkor mindet át kell néznie release előtt.

 

Szerintem sokan elfelejtik, hogy itt emberi rostán mennek át a dolgok és nem egy automata rendszer fogja az addigi PR-okat és húzza be.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

hiszti. *asit*. jol meg van fizetve, es faj, hogy dolgoznia kell. boo-fucking-hoo.

Szerintem inkább itt az van, hogy nem úgy mennek a dolgok ahogy ő pont elképzelte és ledobta a hisztit. Alapvetően egyetértek vele, hogy ha lehet ne hagy mar az utolsó másodpercre a patch beadását. Azonban attól még neki is realizálni kéne, hogy a folyó szokta vájni a folyómedret. 

De mi az, hogy "utolsó másodpercre"? Mindig van egy határidő, annak mindig van egy utolsó másodperce. Ha egy óra van egy dolgozat megírására, azt akkor te beadhatod az első és az utolsó másodpercben is. A probléma az, hogy itt Linus kijelentette, hogy egy óra van a dolgozat beadására, közben meg úgy gondolja, hogy ő abban az egy órában ki is akarja javíani, elenben az már egy másik lépése a folyamatnak. Persicsb ezt szépen leírta fentebb.

Igen, mint az köztudott az "Amit ma megtehetsz, ne halaszd holnapra" egy régi finn közmondás és abból is a hibás fajta.

Valójában, sokkal bölcsebb kicentizni a határidőt mindig! Remélem, ha lesz gyereked, ezt a nagy bölcsességet majd átadod, alkalmaztatod vele és ha nem úgy tesz, konzekvensen számon kéred rajta. :D

trey @ gépház

Valójában, sokkal bölcsebb kicentizni a határidőt mindig!

Nem értem.

Tegyük fel, hogy hétvégén akarsz release-elni valamit. Akkor nem azt mondod, hogy hétfőtől péntekig küldhetnek PR-t, majd behisztizel, ha valaki csütörtökön küldi csak el, hanem eleve azt mondod, hogy hétfőtől szerdáig jöhetnek, mert csütörtök-pénteken review-ztok és teszteltek.

Hogyne, rendszeresen.

Általában a határidőket is ennek figyelembe vételével terveztem. Ha tudom valakiről, hogy rendszeresen csúszik, akkor nem péntekig kérem tőle azt, amivel hétfőn már egy másik team dolgozna. Ha meg olyan volt a helyzet, kellett egy kis mikromenedzsment, és naponta-kétnaponta megnézni, hogy hol tart a feladat. Ha egy feladat nincs a kritikus úton, egy kis csúszás belefér, ha előre tudunk róla, és nem aznap derül ki, hogy kell még két hét. Ha ott van, akkor vastagon kell fognia a ceruzának a határidők tervezésekor.

De nem érted. A notórius csúszónak megadhatsz bármilyen határidőt, akár biztonságból neki külön egyet, vagy többet is a biztonság kedvéért, akkor is baszni fog rá. Ideig-óráig lehet, hogy betartja, majd kezdődik újra.

On Tue, 19 Aug 2008, David Miller wrote:
>
>  114 files changed, 1533 insertions(+), 898 deletions(-)

David, this absolutely _has_ to stop.

We're after -rc3. Your network merges continue to be too f*cking large,
and this has been going on for many months now.

Tehát:

                         |  ------------------------------ 2 hét ------------------------------------------ |   ------  1 hét -----  |   ------  1 hét -----  |  ------  1 hét -----  |  ------  1 hét -----  |

végleges kiadás -> merge window open -> merge window -> merge window bezárva, -rc1 ->             -rc2        ->           -rc3                       -rc4

                                                                                                                                  ^                                             ^  

                                                                                                                               határidő                            és küldi és küldi és küldi    

if you cannot throttle people, I will have to throttle you and stop pulling things.

I'm going to take this, but really - this isn't just new drivers or
something like that that you've used as an excuse for big pulls before,
this is a _lot_ of changes to existing code.

Tell your people to look at the regression list, and if it's not there,
they should stop.

I realize that this problem is partly because when I see the pull requests
from you, I effectively see a combined pull from multiple different
sources, and in that sense it's not quite as big. But the networking pulls
have _consistently_ had the problem that they keep on being big not just
after -rc3, but after -rc4 and on, and I get the distinct feeling that
you're not moving the pain downwards, and aren't telling the people under
you to keep it clean and minimal and regressions only.

 

Vagyis a Linus alatt levő alrendszer karbantartó az, aki nem tartja / tartatja be rendesen a határidőket és szabályokat.

Ez 2008. Milliószor láttam már szólni Linust, hogy ezt fejezzék be. Nem igaz, hogy Dave S. Miller és a többi maintainer, aki alatta van, nem tudja ezeket. Egyszerűen vagy szarnak bele, vagy nem akarnak konfrontálódni az alattuk levő fejlesztőkkel. Teljes mértékben megértem Linust és a kirohanását.

trey @ gépház

"alatta van". neki dolgozik, vagy mi a fasz?

Egy korábbi slide-ot tudok neked mutatni arra, hogy mit jelent az, hogy alatta van. Annyit változtass rajta fejben, hogy s/Andrew Morton/Greg Kroah-Hartman/:

Az ábrán a "subsystem maintainer" az, akikkel gondja van. Közülük vannak, akik évtizedek óta ugyanazok:

https://i.imgur.com/iRvhfQ5.png

trey @ gépház

Arról beszéltem feljebb, legalább 3 alkalommal, hogy írjátok le, hogy milyen eszköz van Torvalds kezében, amivel jobban rá tudna hatni az emberekre, mint a nyilvános pellengérre állítás, amit most tesz. Azóta is várom. Szóval, ja, hobbibagázs. De attól még, hogy hobbi, a balfaszokat meg lehet nevezni. Ha pedig így tesznek, akkor illene azoknak magukba nézni.

trey @ gépház

hogy milyen eszköz van Torvalds kezében, amivel jobban rá tudna hatni az emberekre, mint a nyilvános pellengérre állítás,

Pl. Hogy megszab PR deadline-t és nem fogad be újabb patchet a deadline után. Hagy a PR átnézésére időt (merge window), majd jön a merge.

amit most tesz

Amit most tett az a hiszti, ezt mindenki felismeri, talán mindenki csinálja is. Ettől totálisan 0 hatása van azon kívül, hogy hírt generál.

 

Ebben a kérdésben nem számít igaza van Linus-nak vagy se.