should the kernel have an engineering council?

Posted Jun 12, 2024 9:47 UTC (Wed) by danielkza (subscriber, #66161)
Parent article: Extensible scheduler class to be merged for 6.11

It's nice to see Linus injecting some sanity into the discussion, but it would be preferable to have a process of some sort so these kinds of deadlocks can be resolved in a consistent way.

I believe there kernel should have something analogous to distributions' Engineering Councils to settle these types of disputes. While maintainer authority is important, there must be checks to stop it from being used across reasonable subsystem barriers and/or in obstructionist ways (even if with good intentions).

should the kernel have an engineering council?

Posted Jun 12, 2024 12:21 UTC (Wed) by khim (subscriber, #9252) [Link] (1 responses)

Linus may always override any decision of any maintainer.

He uses that superpower very rarely, which is precisely how he may keep it: every time Linus does that some people become angry at him, obviously, and frequent application would make community leave Linus, but as long as he uses such superpower only once a year or even less often the majority of developers support him.

At some point kernel community would need to find a way to do that without Linus, but that that bridge would be crossed when it would be reached, there are no rush.

should the kernel have an engineering council?

Posted Aug 17, 2024 12:11 UTC (Sat) by Lennie (subscriber, #49641) [Link]

Well, at the moment if Linus somehow wasn't available long term, things would stay the same, except it would just be someone else at the top like Greg Kroah-Hartman.

Current process is appeal to Linus

Posted Jun 12, 2024 12:24 UTC (Wed) by farnz (subscriber, #17727) [Link]

It does have such a process at the moment; Linus is the final arbiter (analogous to an "Engineering Council"), and if there's a deadlock that you think should be resolved in your favour, you go to Linus to get things resolved. Linus trusts his chosen maintainers, so the process is biased in their favour, but if they're being donkeys, Linus will break the deadlock - in the extreme, by doing what he's doing with sched_ext and merging it over maintainer objection.

Ultimately, the current kernel is structured with Linus as benevolent dictator; all a Council or Committee can do is make suggestions to Linus, and see if he takes them. Of course, the same applies to maintainers; while they suggest changes to Linus via pull requests, he has the ultimate authority over what changes will and will not be accepted.