[arlort]

I don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures

[timewizard]

> then he should have shut the discussion down long ago

It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.

In any case, perhaps it's worthwhile to remember where it started, and what the attitudes were at the time [1]. It was an experiment. Experiments sometimes fail or reveal themselves to not lead anywhere useful. The choices were to let that experiment happen on the actual kernel or force the rust people to fork some version of the kernel and instantly be left behind.

It clearly wasn't an easy choice and I can only imagine the uproar from the rust community if he then did what you suggest today. So, that leaves us with the question, what if he's decided it's no longer worth it? What then should we do with a mostly failed kernel experiment?

[1]: https://www.zdnet.com/article/linus-torvalds-on-where-rust-w...

[arlort]

> It's interesting that people expect Linus to simultaneously chill out and be more inclusive while at the same time acting like a dictator over the entirety of the project.

It's not particularly interesting that different people have different expectations on different issues

[timewizard]

It's interesting that you moved the goalposts to an entirely different point. I'm clearly talking about the overall "community," which whether you care about it or not, has been used as a point to successfully force Linus' hand before.

In other words, there are clearly politics involved, so perhaps that should be taken into consideration before making a blithe point about a complex human organizational issue?

[okanat]

You can be decisive and inclusive without being a prick who is personally targeting developers and publicly demeaning. Linus was like that. No sane developer wants that. A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.

It is not really a good experiment in technical qualification nor in developer collaboration, if the leadership lets individuals to constantly blockade work, isn't it?

[timewizard]

> personally targeting developers

How else would you target them? You can disagree over tone and scope but this is an open source project with an open contribution model.

> publicly demeaning. Linus was like that. No sane developer wants that.

Show me someone who hasn't been turned to this behavior over frustration. In isolation you can always find this from a leader what you should be concerned with is context and persistence. While it was occasionally over the top the majority of the time he was perfectly "sane."

> A true inclusive environment also requires leaders to tell rowdy maintainers calling people "cancer" to know their place and watch their tone.

This is open source. What exactly is "their place?" How much time should one dedicate to policing tone? Isn't that personally targeting people but in a different direction?

Which is part of my point here. Previously we just developed and ignored Linus' hot head behavior. This push for a vaguely defined "truly" inclusive community is what I feel led Linus into the mistake of allowing Rust into core.

> if the leadership lets individuals to constantly blockade work

What if the work just isn't very good or is counterproductive to the project as a whole? What if there is no consensus on this point? How much time should one dedicate to building consensus?

[gauntletstricky]

archive.ph/rESxe

>Thinking of literally starting a Linux maintainer hall of shame. Not for public consumption, but to help new kernel contributors know what to expect. >Every experienced kernel submitter has this in their head, maybe it should be finally written down.

https://lore.kernel.org/rust-for-linux/CAHk-=wi=ZmP2=TmHsFSU...

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

Hector Martin went way beyond being a "prick". And Linus Torvalds told him to stop it.

Have you considered that the problem may be the people that are making "hall of shame" lists of people and doing social media brigading?

Worsening matters, Steve Klabnik (major Rust community figure, has run @rustlang, primary author of the Rust Programming Language Book, former Rust Core member, and moderator of r/rust), have been busy here and on reddit making excuses for Hector Martin. What kind of community is the Rust community?

[steveklabnik]

I have never moderated /r/rust.

I haven’t been involved with the Rust Project for years, I speak only for myself.

I said that I feel for Hector, he’s clearly hurting, and that I hope he feels better. I’ve said I don’t want to pass judgement on if what he did is right or wrong, because I’m trying to stick to facts here. I’ve said that I don’t think what he did was particularly effective.

That’s not making excuses. Hector’s actions aren’t the main point of this story. It’s not even his patch!

[gauntletstricky]

>rowdy maintainers calling people "cancer"

Where was this done? In the recent mailing list, the maintainer never called people cancer, he said

https://lore.kernel.org/lkml/[e-mail]/

>And I also do not want another maintainer. If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade).

Not referring to people. And many developers would agree that a multilanguage codebase can easily end up becoming a nightmare and pure cancer to maintain, whether or not Rust is one of those languages.

Another C project has not had good experiences with all interop attempts, pulling the plug on interop with one Rust library, while keeping support for two other Rust libraries.

https://daniel.haxx.se/blog/2024/12/21/dropping-hyper/

>Before this step, we supported three different backends backed up by libraries written in rust. Now we are down to two: rustls (for TLS) and quiche (for QUIC and HTTP/3). Both of them are still marked experimental. >These two backends use better internal APIs in curl and are hooked into libcurl in a cleaner way that makes them easier to support and less of burden to maintain over time.