A question I've had on my mind for a while:
In the Linux kernel, what is the reason to have a "subsystem trees" model instead of a central tree with one main branch and one "next" branch, into which any maintainer can accept changes for their subsystem?

Is it only so that Linus Torvalds can reject changes before they land, and to make it less technically complex to enforce that kernel.org servers can't modify code releases?

@jann I'm getting gray hair thinking of managing merge conflicts with people that haven't even accepted the migration to git.

My experience has been that people are terrible at integrating their trees with each other. I can only rely on a few subsystem maintainers to do stable trees with each other.

I don't need the -next experience myself. I happily let @broonie carry that torch.

@jann The rate of change would be too high for a lot of people to work on effectively - for example one of the issues people have with testing -next is that you can get disruptive changes in some unrelated subsystem that cause your testing to fall over, things like breaking build or boot never mind an actual integration issue. The separate trees can all be individually stabilized and the integration issues dealt with separately.

@jann There are maintainers who don't fully get Git basics, e.g. rebasing effects or branches (that merging a branch does not rebase anything), so if I was Linus T., I would not give them access to my tree...

Proficiency in Git is as needed as proficiency in English and programming language. And many of us are not proficient in these... which is fine, btw.

@jann there’s also that a lot of their workflows are still based on emailing patches around

@jann I genuinely do not know, but I really wish that Linux used a more modern workflow that (a) associated proper metadata with each patch and (b) did not use SMTP as a transport.

@jann Hmm, @brauner, @krzk, and @broonie all gave good reasons, but I wonder if the real/main reason is simply:

"It just happened that way" (aka historic reasons) together with a bit of what @broonie said and "Linus likes to be in control".

I mean, in the beginning, there wasn't even a VCS for many years, so you had to send things to Linus. And that stuck with bitkeeper/git.

And given that Linus looks at the changes submitted to him and pushes back sometimes, it looks like he wants it that way (and "no, I won't take those changes" is likely also the better approach than "I don't like those changes you pushed to the repo, I reverted them").

And he like the "stabilize separate trees" model, too (e.g. what @broonie said). And I think that was the case even in the bitkeeper days already.

@kernellogger @jann @brauner @krzk Yeah, there’s definitely an inertia element too - you’d have to make a conscious decision to transition and for a long time that just wasn’t even an option.