The elephant in the room

Posted Feb 10, 2025 18:56 UTC (Mon) by roc (subscriber, #30627)
Parent article: Maintainer opinions on Rust-for-Linux

is that Linus still has to decide whether a single maintainer opposed to Rust in the kernel has the power to veto the entire project.

The elephant in the room

Posted Feb 10, 2025 19:04 UTC (Mon) by andreashappe (subscriber, #4810) [Link] (5 responses)

I think he did a couple of days ago: https://lkml.org/lkml/2025/2/6/1292

reading through the thread (as well as through the lwn.net comments) was quite interesting. Lots of misquoting. I really liked the moderate takes (from both sides) and the calmed-down approach by dave airlie, etc.

The elephant in the room

Posted Feb 10, 2025 19:32 UTC (Mon) by dralley (subscriber, #143766) [Link] (2 responses)

He addressed Marcan's behavior, he did not address the original topic of discussion (at least publicly) in any way.

It is extremely that he will merge the patch when it is submitted to him in the merge window, regardless of CH's NACK. But I personally wish he wouldn't just let the subject sit there and generate drama in the meantime. Even if the R4L devs themselves know what's up, it discourages everyone on the outside and leads to needless negativity.

The elephant in the room

Posted Feb 12, 2025 20:41 UTC (Wed) by plugwash (subscriber, #29694) [Link]

I can see why he doean't though, if he explicitly acks the patch in a mailing list post, then marcan's supporters can parade that post round as a victory.

If he just quietly merges it as part of a big merge that is much harder to do.

The elephant in the room

Posted Feb 12, 2025 21:01 UTC (Wed) by jmalcolm (subscriber, #8876) [Link]

My first take was similar. However, I can see here how getting into the middle of the debate may do nothing positive and just fan the fire. Regardless of his take, it is just more to argue about. And, given the divide, it would take A LOT of pinning down to prevent endless goalpost moving in the replies.

Linus has a unique super-power. He gets to decide what to merge and what not to (not in a sub-system but in the kernel). In the end, kernel maintainers only authority comes from the fact that Linus takes takes submissions from them.

So, the ultimate statement from Linus will simply be if he merges the Rust changes or not.

If he does, that is not only a VERY strong statement but it destroys the entire argument being leveled against Rust here. Once it is in, it is in. The whole "I need to maintain absolute purity to prevent the cancer" line of reasoning evaporates almost completely.

If Linus rejects it, he has the choice of again making it a very strong statement or of being very clear about the the technical reasons for the rejection. In which case, the whole thing because a technical debate as it should be.

In the end, I think Linus is making the right decision to keep his powder dry for the real strike taken at merge time. I also think this supports his ability to take a hard-line against the "social" side of the issue now and then the technical side of the issue later when he merges the code.

The elephant in the room

Posted Feb 10, 2025 19:36 UTC (Mon) by boqun (subscriber, #154327) [Link] (1 responses)

> I think he did a couple of days ago: https://lkml.org/lkml/2025/2/6/1292

I think that response was particularly addressing Hector Martin's

"If shaming on social media does not work, then tell me what does, because I'm out of ideas."

and not for the posted patchset or any Rust-for-Linux process.

Although I appreciate Hector's support for Rust-for-Linux project, I must say I don't fully agree with what he proposed there.

> reading through the thread (as well as through the lwn.net comments) was quite interesting. Lots of misquoting. I really liked the moderate takes (from both sides) and the calmed-down approach by dave airlie, etc.

The elephant in the room

Posted Feb 11, 2025 6:58 UTC (Tue) by tchernobog (guest, #73595) [Link]

Shaming on social media is obviously wrong.

But there is a double standard at play here, if shaming on a public kernel mailing list is accepted.

They might have different reach and the way you "post a message" might be different, but the result is the same.

This is why I am disappointed that Linus's response is only addressing one half of the issue.