This was painful for me to read as someone who has seen how corporations think about “Open Source” - he isn’t wrong at all
Some maintainers are rejecting changes as a way to block a project they disagree with - ie. there is no path forward for the contributor. I wouldn't assume this normally, but they're not hiding this fact, it's self proclaimed.
On the other hand, Linus has been largely in favour of the R4L project, and gave the green light for it to go ahead.
The Linux kernel maintainers need to figure out among themselves whether they want to allow Rust to be introduced or not, and if so under what constraints. If they can't come to an agreement, they're wasting everyone's time.
Once that happens, either the project is canned, or people can stop arguing over if these changes should be upstreamed, and start arguing over how instead, and that's a lot more productive.
It's yours.
If you need someone to do free work but you can't convince them then you either get their boss to tell them to do it, you take over their job, or - the one thing that no one under 30 ever seems to do - fork and do the work yourself without anyone stopping you.
It is the maintainers job to determine whether a project should be pursued at all.
If a maintainer says "yes I'd be happy to accept feature X", and then simply rejects all PRs implementing X without giving feedback then they're a bad maintainer!
That's essentially what's happening here due to the fact that the kernel maintainers have not come to a coherent decision regarding R4L.
If you're asking them to accept your code then yes, you' are asking them to support your project forever.
If you weren't sending them patches then they couldn't block you. Since you are they can.
Again, it's not their job to support this great idea you have that means they have to change how they've done everything for the last 30 years.
That is to say, if you are building an tool as a collaborative open source project, then that implies that you intend to collaborate.
It works both ways. If you have a beef, don't be surprised if someone responds to it in a way you don't expect or like.
So far, I haven't seen discussions from both sides of the wall. But I hear a lot of noise from one side of the wall trying to get the attention of people on the other side of the wall. Now we will see if the people inside the wall think there is an issue with the gate.
Then say that. A big part of the issue is that there has been mixed signals from the Linux maintainers about R4L. Linus seemed to have supported it, and others are trying to block it.
The maintainers should get on the same page about the inclusion of rustlang code, and communicate that.
> If you weren't sending them patches then they couldn't block you. Since you are they can.
One of the big turning points of this drama was a maintainer from a different area (who had been CCed on the threads, but was not the person the patch was being submitted to) blocking a patch that they weren't going to have to maintain.
But saying that he is't going to have have any additional maintenance burden just because the rust code using his subsystem is in a different subtree is also not an honest assesment of the situation. That's not how the kernel developent works.
In the related submission on this topic [1], the author makes this argument in a lot more detail, that it's essentially impossible to make a Linux fork sustainable without massive investment that no one can realistically obtain.
I do also understand the frustration when an open source project strings you along (me: can I join your club?), ask for this and that (them: sure if you pay your dues), ensuring your cover every "important" person's pet use case (them: and also buy us lunch), then publicly snark about the whole thing (them: this new guy know about no mustard on the lunch!) and kill your failing motivation (me: oh, sorry).
That's why the fork is so appealing. If it's good enough for long enough you get to join the club.
If Rust truly is zero overhead on the C side of things then they should be just able to fork Linux indefinitely without any worry about what upstream does. Just fast forward every change and you're golden.
Then they can write every driver they can imagine to their hearts' content.
The fact they aren't doing this tells me that the promise that this won't impact C people at all isn't much of one.
It's like telling people who want JPEGXL in Firefox to "just" fork the browser, ignoring the massive extra effort that you actually have to convince everybody to use your fork instead of the original.
Talk about aggressively missing the point.
Rust developers are promising that rust in the kernel should have no impact on c in the kernel.
If rust in the kernel has no impact in c then you should be able to remove the rust from the kernel and move it to it's own project, since it will have no impact on the c either way.
This is primarily around Rust filesystem drivers. If you want to run a filesystem but it's implemented in Rust, you'd have to use that fork. If another person had the same issue (say a GPU driver that some maintainer decided they didn't like because of the country of origin or some other petty reason), then that would have to be a fork as well. Suddenly, you can't use that GPU with a Rust-implemented filesystem, because you have to pick one of the forks, or you have to make your own merged kernel from the two.
"Just fork it" doesn't work here. It's a logistical nightmare.