you want your merges in? patch it in your own branch
the real crux of the issue is the quality of "the offical version", the real issue, then, is about official branding.
I remember back in the day there were multiple kernel versions by different mantainers.... then again I'm probably missing the forest for the trees or something
The Linux kernel quite intentionally makes maintaining a fork a pain in the ass to pressure vendors to mainline their drives. But now mainline maintainers are refusing to accept those drivers. So it's unlikely we will ever see Macbooks properly supported on Linux.
> Out of tree doesn't work. People, both in the kernel and out of the kernel, want things in tree.
https://lore.kernel.org/lkml/1e8452ab-613a-4c85-adc0-0c4a293...
This is why forks made for specific devices are seldom updated for more than a few months (or a couple of years if you're very lucky).
I feel like this problem should have a technical solution.
maybe a VCS good enough that this isn't as big an issue? (along the lines of pijul?) or
maybe something from formal verification methods to better enforce or more clearly explain why some drivers cannot be accepted. then again, I don't think the computer science is quite there yet
Either the change is accepted upstream meaning that everyone else making changes to the mainline needs to keep it working, or it isn't and they don't.
If your code is out-of-tree, every time someone changes an API that break your build, it's your responsibility to update your for and fix it.
If your code is mainline, the people who change API and break the compilation are on the hook to fix it.