Comment by firesteelrain
10 months ago
Staying away from the emotional part of this blog post.
I was about to write a question to ask why, if these downstreams are forked, that it is such a big deal to be gatekeeping the upstream and I think I got my answer from this:
"In fact, the Linux kernel development model is (perhaps paradoxically) designed to encourage upstreaming and punish downstream forks. While it is possible to just not care about upstream and maintain an outright hard fork, this is not a viable long-term solution (that’s how you get vendor Android kernel trees that die off in 2 years). The Asahi Linux downstream tree is continuously rebased on top of the latest upstream kernel, and that means that every extra patch we carry downstream increases our maintenance workload, sometimes significantly. "
Is it wrong for Linus to take the side of the kernel and not of the various distros? Serious question. I don't completely understand all of the background here.
"But it goes deeper than that: Kernel/Mesa policy states that upstream Mesa support for a GPU driver cannot be merged and enabled until the kernel side is ready for merge. This means that we also have to ship a Mesa fork to users. While our GPU driver is 99% upstreamed into Mesa, it is intentionally hard-disabled and we are not allowed to submit a change that would enable it until the kernel side lands. This, in practice, means that users cannot have GPU acceleration work together with container technologies (such as Docker/Podman, but also including things like Waydroid), since standard container images will ship upstream Mesa builds, which would not be compatible. We have a partial workaround for Flatpak, but all other container systems are out of luck. Due to all this and more, the difficulty of upstreaming to the Linux kernel is hurting our downstream users today."
I think we are dealing with a maintenance problem of downstream forks and trying to make their lives easier by convincing the kernel maintainers to accept the changes upstream.
Does Linux have a standards committee or some sort of design committee? I thought they had something to decide what goes in and what doesn't. If it doesn't then is it necessarily gatekeeping then? It seems like someone has to make the hard technical choices whether something becomes part of Linux or not and that is what Linus is doing.
I am trying to understand the real issue here. It seems like the difficulty in upstreaming changes to help the downstream folks is the issue not necessarily that the downstream folks are blocked.
I was thinking the same on this. It is a classic case of division of responsibility. The argument appears to be: should we force a small number of downstream maintainers to suffer a big maintenance burden or should we make upstream handle a smaller burden.
Martin's position rests on his claim that the big maintenance burden he would be forced to bear is unfair. I mean, he is the one who chose Rust. No one forced that on him. It is kind of hard for me to see his claim that the maintenance burden of his choice is somehow the responsibility of the upstream maintainers who are all C developers, no matter how small he insists such maintenance would be. My own opinion is that he made his bed, he needs to sleep in it. Or wait for the tides to change in his favor over Rust inclusion in the kernel. All of this crying foul just doesn't sit well with me.
Agree, these are not the real issues. He has some personal issues going on and is blaming this thing or things as the source of his problems which they are not. It seems he needs some emotional maturity and resilience too.
>Is it wrong for Linus to take the side of the kernel and not of the various distros? Serious question. I don't completely understand all of the background here.
Linus is pro-R4L. He wants to see Rust drivers in the kernel upstream, and has expressed frustration that it has been such a slow process, and that he doesn't understand why some maintainers turn it into a religious issue.
The problem is that he hasn't done much in the way of actually standing up against arbitrary stonewalling by those maintainers. This ensures that everyone gets pissed off and creates a giant mess of arguments. Rust people get pissed off because they were told their contributions were welcome and feel like their time investment is being wasted on bullshit, and C maintainers because the lack of a clear policy leads to ruminating and imaginations running wild.