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.