Comment by Tomte
10 months ago
He has at least said this to Martin: "How about you accept the fact that maybe the problem is you." (https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...)
I wouldn‘t expect a grand Rust announcement anytime soon, above what has already been said. Rust in the kernel seems to be fine, but it will have to adapt to longstanding kernel processes. And if it means there won‘t be Rust in some maintainers‘ subsystems, so be it. The kernel won‘t be 100% Rust next year anyway.
I've conversed with marcan a few times (on completely unrelated and inconsequential things). As far as I know he's a decent man.
That said, I'm going to agree with Linus there: Cancel culture ("social media brigading") isn't the solution.
Indeed, but where is the 'real' solution? If no-one higher up is going to step in and merge the patches despite the blocking maintainer, how is "the process" going to move R4L forward?
(Edit: Ok, reading some other context, it seems like this is indeed what's happening, which does make this reaction a little less justified. I can certainly see why it's no fun to have people in the project saying they will do whatever they can to stop an initiative, but if they aren't actually able to block it, then it doesn't seem worth quitting over)
They can merge regardless. The maintainer nacked something they don't even own, they were asked for a review as a courtesy as it wraps their subsystem.
That said there's an outstanding question about whether Linus would accept something that breaks Rust builds for merge. Linus hasn't commented on this yet, but I'm sure he will.
Sometimes there's no win-win-win solution.
I think people who write C should stop unless it's to fix security bugs and should do something else, anything else, maybe even learn about programming. But even with this mindset Linux is a C project and the R4L folks promised to thread the needle, if it cannot be done this time, then it cannot be done this time. They need to wait.
4 replies →