5 ms·

The thread didn't really have drama before marcan stirred the pot. There was a disagreement, but the individuals pushing for the merge were not attempting to es

The thread didn't really have drama before marcan stirred the pot. There was a disagreement, but the individuals pushing for the merge were not attempting to escalate, only try to find a path forward in a way that might make both parties happy with the compromise. The drama and social media outrage arguably did nothing to help, and as far as I can tell, simply makes for good entertainment for onlookers who like to gossip. While it would be nice to have Linus help out here with a clear resolution after escalation, it's clear to me that the behavior marcan displayed is the higher priority problem to address.

adgjlsfhk1 2y ago
I think this isn't the right take. the "disagreement" was a kernel maintainer saying "Rust in the Linux kernel is a mistake and I will do everything in my power to sabotage Rust adoption" (as feedback on version 8 of a patch). The fact that open undermining of Rust for Linux receives no pushback from Linus or anyone else with power in the Kernel is shocking.
- stirlo 2y ago
  100% this. Yes, Hector went nuclear, but he begged Linus to step in and provide leadership (either merge or reject) and instead Linus ignored the whole technical issue with regards to rust being totally blocked. Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux. No wonder why people are giving up (exactly what the blockers want).
  - o11c 2y ago
    Counterpoint: prior to going nuclear, is there any evidence that Marcan directly tried to get Linus's attention, given the huge quanity of mailing-list mail Linus is sure to get every day? I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that would've gotten in the way of "send a PR despite the Nacked-by", which has been done in the past.
    - nrabulinski 2y ago
      He literally says in the post he reached out to Linus directly and to this day haven’t gotten a response. He also himself was (trying to) upstream patches for years, usually ending up similarly getting stonewalled
      - o11c 2y ago
        I don't see the word "reach" or any relevant mention of "Linus" in either the "shaming" post or in the resignation post. Even if there was, I'm not sure I trust the word of such a drama-seeker directly, so it's reasonable to a evidence of on-mailing-list appeals adding CC (as Danilo did), and if that fails mention of contacting Linus off-list in that specific subthread.
        deleted 2y ago
        [deleted]
  - dralley 2y ago
    >Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux The suitable path forward is to submit the patch series like normal to Linus, where it will be merged regardless of CH's NACK. CH isn't able to actually stop this process, he's just being a jerk. However, I agree with you that it would have been nice to actually publicly clarify the situation rather than ignore it and deal with the whole thing behind closed doors. It shouldn't need to be explained that letting this sort of thing fester is a great way to kill motivation in a project and ensure it's less likely that new people will get involved.
    - Den_VR 2y ago
      The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation. In practice, CH is doing everything he can to stonewall and sabotage efforts to subsequently bring Rust to solve problems. This explosion, now, was plainly a consequence of months and months of failure. And that anyone name-calls to blame that failure on “a drama-seeker” leaves me to wonder about the future of Linux 20 years from now.
- surajrmal 2y ago
  The rust project is not stalled. There is pushback from maintainers, but as trust is established, things will hopefully change and it'll get easier. Escalating erodes trust and simply will make the process take longer. Anything that fuels us vs them narratives are simply damaging. Everyone needs to focus on the shared objectives of the overall Linux project. Ignoring the maintainers and pretending their opinions are wrong or don't matter won't help. I'm not sure a top down directive is necessarily the right way to establish a healthy space for rust in linux.

adgjlsfhk1 2y ago

I think this isn't the right take. the "disagreement" was a kernel maintainer saying "Rust in the Linux kernel is a mistake and I will do everything in my power to sabotage Rust adoption" (as feedback on version 8 of a patch). The fact that open undermining of Rust for Linux receives no pushback from Linus or anyone else with power in the Kernel is shocking.

stirlo 2y ago
100% this. Yes, Hector went nuclear, but he begged Linus to step in and provide leadership (either merge or reject) and instead Linus ignored the whole technical issue with regards to rust being totally blocked. Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux. No wonder why people are giving up (exactly what the blockers want).
- o11c 2y ago
  Counterpoint: prior to going nuclear, is there any evidence that Marcan directly tried to get Linus's attention, given the huge quanity of mailing-list mail Linus is sure to get every day? I only see Danilo doing that in that thread. And admittedly Linus didn't respond (and Greg KH only minimally responded). But even CC probably means a lot of mail for top maintainers, and at that point I don't see anything that would've gotten in the way of "send a PR despite the Nacked-by", which has been done in the past.
  - nrabulinski 2y ago
    He literally says in the post he reached out to Linus directly and to this day haven’t gotten a response. He also himself was (trying to) upstream patches for years, usually ending up similarly getting stonewalled
    - o11c 2y ago
      I don't see the word "reach" or any relevant mention of "Linus" in either the "shaming" post or in the resignation post. Even if there was, I'm not sure I trust the word of such a drama-seeker directly, so it's reasonable to a evidence of on-mailing-list appeals adding CC (as Danilo did), and if that fails mention of contacting Linus off-list in that specific subthread.
      - deleted 2y ago
        [deleted]
- dralley 2y ago
  >Even now with Hector out of the picture, there’s still no suitable path forward for rust in Linux The suitable path forward is to submit the patch series like normal to Linus, where it will be merged regardless of CH's NACK. CH isn't able to actually stop this process, he's just being a jerk. However, I agree with you that it would have been nice to actually publicly clarify the situation rather than ignore it and deal with the whole thing behind closed doors. It shouldn't need to be explained that letting this sort of thing fester is a great way to kill motivation in a project and ensure it's less likely that new people will get involved.
  - Den_VR 2y ago
    The reasoning Linus himself gives for greenlighting Rust is, among other things, to avoid stagnation. In practice, CH is doing everything he can to stonewall and sabotage efforts to subsequently bring Rust to solve problems. This explosion, now, was plainly a consequence of months and months of failure. And that anyone name-calls to blame that failure on “a drama-seeker” leaves me to wonder about the future of Linux 20 years from now.
surajrmal 2y ago
The rust project is not stalled. There is pushback from maintainers, but as trust is established, things will hopefully change and it'll get easier. Escalating erodes trust and simply will make the process take longer. Anything that fuels us vs them narratives are simply damaging. Everyone needs to focus on the shared objectives of the overall Linux project. Ignoring the maintainers and pretending their opinions are wrong or don't matter won't help. I'm not sure a top down directive is necessarily the right way to establish a healthy space for rust in linux.