A kernel code of conduct enforcement action

The Linux Foundation Technical Advisory Board (TAB) has decided to "restrict Kent Overstreet's participation in the kernel development process during the Linux 6.13 kernel development cycle" based on a recommendation from the Code of Conduct committee. In particular, the scope of the restriction will be to "decline all pull requests from Kent Overstreet" during the development cycle. Overstreet is the creator and maintainer of the bcachefs filesystem.

This action stems from a message Overstreet posted back in early September that was abusive toward another kernel developer; there is a fair amount of back-and-forth about the incident and the committee's attempts to extract a public apology from Overstreet in that thread. Overstreet has published a lengthy blog post describing his side of the story. to post comments

A note Posted Nov 23, 2024 2:12 UTC (Sat) by koverstreet (subscriber, #4296) [Link] Michal's gotten some hate mail because of this, so I'm going to repeat what I said in the blog post and ask people to please not do that. I doubt any will come by way of lwn (I hope), but I think it still worth saying. The only reason I raised this as far as I did is because I think we do have some cultural issues worth talking about and seeing if I can address. I don't want individuals getting attacked; this was just a personal story to illustrate things that are not terribly atypical for LKML. Why only here ... Posted Nov 23, 2024 2:24 UTC (Sat) by JMB (guest, #74439) [Link] (5 responses) Well, I am following kernel news for a long time - and even though I would not use that words (only in private ... yes - but never in public), it is not extraordinary for LKML. I would really like to have explanation why excluding Russian kernel hackers and deleting them from the maintainers file - without any personal communication - was not officially dealt with by CoC - from my point of view this would be obligatory! This was much more severe - especially if it is true that some of them were not include in any list (which was reported by some news). Giving the impression that Russians may deserve that treatment just by warfare of their gouvenment is also not justifyable in an international environment - except they could change those things or had been involved personally. I understand bad blood - but not such an abuse! The way Rust people were blocked to give a talk - nothing happened - and those videos were sent on exiting the kernel community - and CoC did ... nothing. Sorry, but this is really bad - and will harm the kernel community. And here it is on technical ground - and was treated on a much too high level - or did that happen before? Why now - after so many much worse stories went viral. From my perspective there is no justification for this suspension ... and I don't see that a line is drawn and explained to really do justice - and help in improving the tone to have more professional diskussions on LKML. So from my perspective this was just a bad show ... Additionally - why had been mitigations (some of them without positive effect) entering in a hurry without -rc? - and bcachefs being experimental can not be worked on when real user problems emerged and can only fixed by rewriting passages. Code touching other regions should be limited to the merge window - of cause. But I would understand big code changes if to help users of that FS. So I would like Mr. Corbet to give some insight of why this is played on that level in comparison with much severe problems seen on videos etc. - and other things were not even brought to light. And if one can bring this to perspective so CoC is not a bad show but helping better understanding each other ... an being a more healthy community - this piece is totally missing from my perspective. If this should be fair - I would like to read about problematic behaviour and possible sanctions before these are first used! It is hard to get real information about the line which should be respected. And thus it smells very fishy ... and I could cite a lot of other examples where CoC should have interfered ... but nothing happened. Why only here ... Posted Nov 23, 2024 2:34 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] This seems somewhat rambling and doesn't make much sense. Are you asking why the TAB dealt with this but did not deal with other, unrelated events that in your view are worthy of TAB enforcement actions? The difference is that this was an action taken based on a heated exchange. It is qualitatively different from the other examples you provided, so they can't really be compared. Why only here ... Posted Nov 23, 2024 8:52 UTC (Sat) by patrick_g (subscriber, #44470) [Link] > I would really like to have explanation why excluding Russian kernel hackers and deleting them from the maintainers file - without any personal communication - was not officially dealt with by CoC Because that's not what happened? As far as I know some kernel hackers were excluded because they were employed by firms under international sanctions. The nationality of the hackers are irrelevant. They can be Russian or Japanese or Norwegian, it doesn't matter. What matters is the fact that they were employed by a firm under international sanctions. And Russian hackers working for firms NOT under sanctions were NOT excluded. Why only here ... Posted Nov 23, 2024 9:33 UTC (Sat) by tytso (subscriber, #9993) [Link] LSF/MM sessions are expected to be for discussions, not talks. And in the cast of the Rust session at the LSF/MM, most of the people in the room couldn't understand what they were trying to do with the Rust code that was on the slide. Unlike in lectures, where if the professor gives an incomprehensible talk, the audience just sits and lets it wash over them, it is expected that people stop the speaker and ask the speaker to clarify. The problem was that the speakers chose an example which was too complicated; they may have been proud of the expressive power of Rust, but if the goal is to try to convince people that using Rust for file system code is a good idea, it might have been a tactical mistake. If the speakers had 2-3 hours to give.a tutorial on the Rust language; of its syntax and semantics, then as the climax of the talk, perhaps they could have shown off this super-clever construction. But they ran out of time, because they only had 30 minutes, and they pushed the audience into the deep end of the pool without any preparation --- is it any wonder that a lot of questions were asked and the discussion became tense? So no, I don't think there was any Code of Conduct violation at the Rust session. It is not a CoC violation to have technical discussions; even tense technical discussions. It is fine to attack ideas; where it crosses a line is when people are attacked. The technical points which Kent has raised, for example in his Patreon post, are really beside the point. Regardless of the technical arguments he might have been trying to make, it was the personal attack which went beyond the pale vis-a-vis the Code of Conduct. And while Kent might have been frustrated by the technical discussion, it didn't justify the public personal attack, and the way to repair the harm from a public attack is a public apology. Finally, note that there have been other Code of Conduct violations over the past six years, and the Code of Conduct committee has investigated and stepped in to address them. The only reason why this situation has been exceptional is because it is the first time that an enforcement action has been needed; most of the time, coaching and education from the Code of Conduct committee is sufficient. See the Code of Conduct committee reports here: https://www.kernel.org/code-of-conduct.html Why only here ... Posted Nov 23, 2024 11:12 UTC (Sat) by Lennie (subscriber, #49641) [Link] > I would really like to have explanation why excluding Russian kernel hackers and deleting them from the maintainers file - without any personal communication Sadly, because they were not allowed by the legal department. Why only here ... Posted Nov 23, 2024 13:01 UTC (Sat) by daroc (editor, #160859) [Link] > So I would like Mr. Corbet to give some insight of why this is played on that level in comparison with much severe problems seen on videos etc. - and other things were not even brought to light. I am not Mr. Corbet, of course, but I will point out that LWN did in fact cover the situation that led to Wedson Almeida Filho retiring from the project [1], the removal of maintainers who work for sanctioned entities from the MAINTAINERS file [2], and, indeed, many other newsworthy events within the Linux community. It's true that we don't report on every mailing list fracas; this one is notable because it has caused a new response from the CoC committee, and because it may impact users of bcachefs. If you have tips for stories that you think are particularly notable that we seem to have missed out on, you're welcome to email us at lwn@lwn.net. [1]: https://lwn.net/Articles/987635/ [2]: https://lwn.net/Articles/995186/ Excessive action Posted Nov 23, 2024 2:31 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] (8 responses) Wouldn't a better solution have been to enforce DNI (Do Not Interact) with Michal? This is not a community that people join for pleasure where temporarily expelling someone hurts no one other than the person being expelled. Blocking pull requests seems to me like one of the least efficient actions that could have been taken and the one that has the most adverse effects on kernel development. This isn't to say that the behavior should be ignored, but there are so many alternatives that seem to not have even been considered. At least it's limited to only one development cycle. Excessive action Posted Nov 23, 2024 2:41 UTC (Sat) by dskoll (subscriber, #1630) [Link] Yeah, it seemed out of proportion to me too, though I agree the language and tone was not acceptable. There was a public apology of sorts in the end in this message. But I guess it came after the sanction had already been decided. Excessive action Posted Nov 23, 2024 2:57 UTC (Sat) by koverstreet (subscriber, #4296) [Link] (6 responses) A DNI wouldn't have been appropriate, since we continued to talk about technical stuff. I'm wondering why no one seems to be able to imagine just saying "hey, this seems tense, what can we do to help", _before_ taking some sort of enforcement action. Right now, when things on the list get heated, it often ends up as a dogpile - and then if it gets to that point the CoC just picks whoever mouthed off the worst and slaps them. Hardly conducive to keeping technical discussions on track, wouldn't you say? Excessive action Posted Nov 23, 2024 3:18 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] (4 responses) > Right now, when things on the list get heated, it often ends up as a dogpile - and then if it gets to that point the CoC just picks whoever mouthed off the worst and slaps them. That is a problem. I am hopeful that this action will make enough waves that people rethink the best way to keep things from getting too heated, so long as it doesn't attract so much controversy that development is further derailed. I expect that people will recognize the issues with what happened and will agree with you. I have hope that people will have enough of a nuanced view to understand that it is okay to criticize the TAB's actions without defending or minimizing inappropriate behavior. Excessive action Posted Nov 23, 2024 3:23 UTC (Sat) by koverstreet (subscriber, #4296) [Link] (3 responses) Imagine if people were just nicer to each other. Not just used more nice words, but actually watched out for each other, as colleagues and friends. But the people at the top set the tone, so I think that would have to start there. Secondarily, I do think focusing too much on avoiding heated words and not enough on deeper issues of being able to make progress is a real issue as well, because it means being dismissive in an argument is the safest option. When things get heated I find that there's often something interesting underneath. Excessive action Posted Nov 23, 2024 3:35 UTC (Sat) by cypherpunks2 (guest, #152408) [Link] (1 responses) > Secondarily, I do think focusing too much on avoiding heated words and not enough on deeper issues of being able to make progress is a real issue as well In the past there has been almost nothing done to stop a community from becoming toxic and abusive behavior was accepted from people who were also long-term contributors. People are swinging too far in the opposite direction to fix things, prioritizing polite discourse to such an extent that it can actually inhibit useful contributions. That's not to say that we should go back to the wild west past, but we shouldn't over-correct and create an atmosphere where people fear not personal attacks, but enforcement actions from up high. Excessive action Posted Nov 23, 2024 3:40 UTC (Sat) by koverstreet (subscriber, #4296) [Link] Yep, exactly. And if you'd seen some of what I've had to put up with lately, some of the people at the top never stopped being assholes. And it's not just about striking a balance, that leads to very waffly "will we or won't we" enforcement that just drags things out, where the enforcers don't want to commit but everyone knows they're going to. The only way out is coming up with an idea of what we _do_ want to see. Excessive action Posted Nov 23, 2024 16:02 UTC (Sat) by raven667 (subscriber, #5198) [Link] > Imagine if people were just nicer to each other. Not just used more nice words, but actually watched out for each other, as colleagues and friends. I think the CoC _is_ looking out for you and your colleagues by stepping in and giving you the opportunity to have a break from the stress, anxiety and subsequent anger that underlies the conflict, but your colleagues are ultimately not responsible for control of your feelings and choices in how you respond to frustrating situations, you need to figure out where the fear and anger come from and why it gets you off your game, I don't know you personally I hope you take the opportunity to decompress and come back with a fresh positive outlook. I'm not sure publicly debating randos in the comments on lwn is doing anything except aggravating a fresh wound, I don't think it's going to help you be the best collaborator, advocate and engineer for bcachefs that you clearly want to be. Excessive action Posted Nov 23, 2024 13:44 UTC (Sat) by zeroheure (guest, #165859) [Link] > I'm wondering why no one seems to be able to imagine just saying "hey, this seems tense, what can we do to help", _before_ taking some sort of enforcement action. Not exactly that, but the first reaction was Jonathan Corbet suggested "to calming down a bit". May be you missed his post ? See https://lore.kernel.org/lkml/8734mitahm.fsf@trenco.lwn.net/ Kent's blog post Posted Nov 23, 2024 6:39 UTC (Sat) by geofft (subscriber, #59789) [Link] (1 responses) I appreciate Kent setting out his side of the story in a thoughtful way. But I'm not sure I buy the argument that this sort of work inherently involves being acrimonious with each other in code reviews, even if you're otherwise chummy outside of that context. "Filesystem work is a stressful job" is such an odd claim. Why? IIt's nothing like being a doctor or lawyer or general or diplomat or air traffic controller where situations can deteriorate in seconds and if you aren't doing your best work on zero notice, lives will be lost. It's not even like being an on-call sysadmin/SRE/etc. for a production server whose filesystem is misbehaving. The code in front of you isn't going to change until you run "git pull" and it's entirely at your discretion when to push, too. (Security vulnerabilities are an exception, but the post only talks about them in the context of designs that are known at the time of writing to lead to DoSes, not about a buffer overflow or speculation side channel being discovered and a race to patch it before it's exploited.) It may be a technically difficult and therefore mentally taxing job, but it should be no more stressful than being a sculptor or a carpenter or a poet. I think Kent's examples actually argue that stress makes the job worse: if people hadn't been so acrimonious about the folio reviews, they might have kept conversing to the point of finding that they shared the same long-term vision without needing a third-party mediator to figure it out. In fact the email at issue here is another counterexample: there was nothing about the code itself nor the technical disagreement that required being acrimonious (as evidenced by Kent's levelheaded explanation of the issue in the blog post). There is nothing inherent about Kent nor his interlocutor that meant that conversations must get acrimonious. It was the increasing heat in the thread that made Kent, in his telling, lose his cool and send a message that is objectively beyond the pale (and, in my opinion, still merits an uncomplicated apology). So the answer is that the thread shouldn't have started to get hot in the first place, and people should have stepped in at the first sign of rancor. And I do question the idea that people work best by yelling at each other over their code and then being friendly once it's over. In my experience there are some people who genuinely like intense arguments, and some who find them uncomfortable. There are people in this latter group who have nonetheless learned to perform the intense argument because they want to make some progress with people in the former group. But that does not at all mean they like doing so or that this process does not burn them out over time. If it really does work for a specific pair of people - they can yell at each other as much as they feel necessary over direct email without copying a list, over a call, or whatever, and then it's opt-in. From the stories in the blog post it sounds like heated disagreement is often used not as a tool in itself but a way to push people to expand on technical detail when it isn't forthcoming - to push back against the spreadsheet of decisions without rationale, to cause people to realize that an uninvolved mediator was needed, etc. If this is indeed what's going on, then Linus and the TAB should step in here - maintainers should not be able to block patches without an explanation understandable to at least one of the patch submitter, Linus, or someone on the TAB (which is a _technical_ advisory board, despite its role in CoC enforcement). People who have long-term plans in mind should be encouraged to publicize them. And it seems odd to me to support bypassing a maintainer and landing the patch in Linus's or some other tree directly, while also letting the maintainer continue to hold that role. Either the maintainer had a justified objection, and bypassing will just cause the maintainer to pick up code they'll want to revert (as happened here), or the person should not actually be trusted with the ability to block patches. I do agree with Kent's comments elsewhere in this comment section that this is an overall culture problem and kernel leadership could do a better job of setting the right tone from the beginning. Kent's blog post Posted Nov 23, 2024 7:24 UTC (Sat) by koverstreet (subscriber, #4296) [Link] > But I'm not sure I buy the argument that this sort of work inherently involves being acrimonious with each other in code reviews, even if you're otherwise chummy outside of that context. The fight over whether XFS would have metadata checksumming split the team. How did it all start? Posted Nov 23, 2024 10:36 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (1 responses) Was CoC involved because the (presumably) injured side raised an issue, or are they policing all interactions now, trying to quell all "unprofessional" infractions, even victimless? How did it all start? Posted Nov 23, 2024 15:32 UTC (Sat) by pbonzini (subscriber, #60935) [Link] There is no such thing as a victimless interaction when one party asks the other to have their brain checked. Language can have a chilling effect to the discussion which makes the whole community a victim. It is not a matter of being "professional", whatever that means, it's a matter of being civil and it's perfectly fine to take action when the boundaries of civility are exceeded; no matter how thick the skin of the other person. Bound to happen Posted Nov 23, 2024 11:33 UTC (Sat) by leandro (guest, #1460) [Link] These were, and still are to a great measure, meritocratic communities. People aged, got some half-baked prudence and, in the absence of traditional ethical structures such as the Protestant ethos that made the substract of the cultures the initial developers came from, created these soviets and their constitutions which perpetuate the illness of corporate structures and inject it into our communities. Our civilisation is dying, it would be delusional to think the free software culture would survive it, save a miracle. The next civilisation will hopefully learn from our foibles, but that would be a miracle too. Non-sense Posted Nov 23, 2024 15:01 UTC (Sat) by rbranco (subscriber, #129813) [Link] (5 responses) Projects become victims of their own success when they can take maintainers for granted. We've seen it Python, Linux, etc. The *BSD crowd should take note and avoid this like the plague. Refusing pull requests is nuts. What if the code contains a security fix? Paying a fine would be better. A win-win. Enough with first world problems! BSD Posted Nov 23, 2024 15:13 UTC (Sat) by corbet (editor, #1) [Link] (3 responses) The "*BSD crowd" is actually an interesting case in point. Have a look at the origin stories for some of those BSD variants and think about whether that's what you really want for Linux, or if it's maybe better for us to figure out how to get along with each other? BSD Posted Nov 23, 2024 15:18 UTC (Sat) by rbranco (subscriber, #129813) [Link] (2 responses) The forks were exclusively about technical and not political issues. And they cross-pollinate each other to a extent. BSD Posted Nov 23, 2024 16:15 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses) > The [BSD] forks were exclusively about technical and not political issues That's an absurd distinction, the software projects aren't run by robots, they are run by human people and forks are created when people can't compromise and collaborate successfully on a shared vision. When people value different things that is a political disagreement not a technical one, miscatagorizing these things is going to lead to future misunderstanding of the fundamental nature of conflicts when collaboration breaks down. BSD Posted Nov 23, 2024 16:26 UTC (Sat) by rbranco (subscriber, #129813) [Link] > That's an absurd distinction, the software projects aren't run by robots, they are run by human people and forks are created when people can't compromise and collaborate successfully on a shared vision. When people value different things that is a political disagreement not a technical one, miscatagorizing these things is going to lead to future misunderstanding of the fundamental nature of conflicts when collaboration breaks down. When everything is political, nothing is. The core differences were 100% technical and the forks were a win-win for everyone... Linux has multiple distributions for mostly technical reasons, but now we seem to afford to fork over petty politics. Non-sense Posted Nov 23, 2024 15:32 UTC (Sat) by tuna (guest, #44480) [Link] As far as I understand, Ken Overstreet can post patches on the mailing list as any other user. It is only his pull requests that will not get "pulled" by Linus T.

Leave a Comment