Linux CoC Announces Decision Wrt Kent Overstreet (Bcachefs)
lore.kernel.org
lore.kernel.org
In the end, it's the users that end up suffering. The guy (Hocko) kept making mistake after mistake and Kent struggled to get him to do anything remotely net positive with regard to the issues in that original thread.
I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
And I would say on a whole his behavior after 2018 has been less rude although he is still quite frank when necessary. I think it’s a positive change.
I think Linus’s message from 2018 is good perspective here: when someone behaves in a way that harms the mission of the kernel it’s better to try to change that behavior at the expensive of that person’s contributions for a limited time, rather than having the bad behavior negatively impact all other contributors forever.
One does not need to be abusive to "tell it like it is" (the most common phrase I heard people utter in defense of Linus's abhorrent behavior toward developers.)
Linus was a bully who let authoring the Linux kernel go to his head and inflate his ego.
And of course he's Linus and you're a nobody so nobody will ever listen to the other side of the completely subjective "facts"
Saying to someone “your work is not good enough for me” is a subjective statement; whether or not it is honest depends on whether or not it is reflective of the speaker’s beliefs about the quality of the work.
A leader not speaking up when they receive subpar work is dishonest, and it is fundamentally unfair to the person doing the work.
You would either be mistaken if you believed the earth to be flat, or a liar if you didn't.
That also has absolutely nothing to do with your original claim -- that Linus has been "dishonest" because his opinions about technical matters discussed on LKML aren't objective. There is a fundamental difference between stating a fact ("the earth is a sphere") and an opinion ("this work is not up to my standards" or "I do not agree with your approach to solving this problem.")
Note: being rude in expressing their opinions might make a person an asshole, but it does not make them "dishonest."
Thanks for telling me the point I was trying to make. It's very useful -_-'
> There is a fundamental difference between stating a fact and an opinion
There is, but often people mistake their own opinions for facts.
I'm sure Linus knew perfectly it was an opinion and not a fact because when he spoke about the issue we were having at a conference he kinda glossed over the bits that would have made it at least doubtful he was correct.
But of course people who hadn't read the mailing list and had no context had no choice but to believe he was absolutely right and forced to deal with very unreasonable people.
Had he said the full story, nobody hearing him would have thought he was completely right.
I wasn't party to whatever conversation you had with Linus, so I can't comment on your anecdote or if or how it relates to the argument(s) you are trying to make, other than to point out that nobody is 100% objective. That includes you.
Have a nice day.
Truly, you made your decision before reading what I wrote.
"This isn't good enough, your code is sloppy as shit" - you're being an asshole.
"We have a coding standards and conventions round commenting and formatting. I encourage you to rework your patch with that in mind and re-submit it, because at least on cursory examination, your code looks solid."
"Thank you for resubmitting. This is much more in line with what we prefer. Now we'll be able to take advantage of the work you've done to fix this problem."
https://www.theregister.com/2018/09/17/linus_torvalds_linux_...
> I'm not arguing that what Kent did was right or wrong, but I would be curious to hear what other ways people work with remote developers who are awful, especially when they work for other companies. You can't just fire them, so I understand the frustration here.
They absolutely can "fire" them, by making a decision not to accept any contribution from them.
You are actually arguing that it was right.
> The guy (Hocko) kept making mistake after mistake and Kent struggled to get him to do anything remotely net positive
That’s not really an excuse for abuse. This kind of comment is why we need a CoC committee in the first place. There is something deeply wrong when community members openly state that insulting other people is ok because they are not productive.
> You can't just fire them, so I understand the frustration here.
You can and should just ignore them. It is not mandatory to engage with people you disagree with and find unproductive especially on the internet where filtering them out is not that difficult.
Less extreme but also working is to just engage them less often. If you slow down the conversation, there is less space for them to annoy you.
Kent's comment is on the line, but it doesn't look abusive. Frankly I'm more curious about the assertions rather than the phrasing, which I think is only the offensive part.
Did Michal make mistake after mistake? Did he assert that crashes are better than error handling? Did his comments or actions logically lead to that happening? That does matter in system robustness.
It seems the meat of the statements Kent made were not explored, merely that he said them harshly. Holding back development because someone wouldn't apologize publicly seems pedantic. If Kent is being hyperbolic, ie inaccurate, that's the bigger concern.
In particular, if the goal is to promote more discussion and openness between contributors, having a "committee" involved feels very counter productive. As does demanding an apology.
By all means, empower folks to call others out as rude. Publicly call out what you see as transgressions. But don't do so with a shield of, "I'm speaking for the committee."
I get that things can be harder in other context. But will never agree with personal messages on behalf of a committee, I don't think.
And for the apologies, that is silly. Would be akin to someone getting a citation being responsible to say sorry. Ideally, you want people to feel the need to do that on their own. At young ages, it is understandable to try and teach the formalities of apologies. But, as a formal policy, it robs apologies of any real meaning.
Kent is obviously well-intentioned and acting in good faith. He is also rather difficult to the point where I wouldn't be surprised to see bcachefs removed from the kernel at some point. It seems to me that mediation and help to deal with his attitude would be far more constructive and appropriate, not punishment.
I suppose that sums up why I don't care too much for the CoC stuff: it's too much focused on "punishment", and typically results in a committee deciding who is and isn't deserving of it.
https://www.patreon.com/posts/trouble-in-116412665
I don't think what Kent did was right, but I'm also not sure this kind of heavy-handed approach by the CoC team is good, either. The forced public apology sounds a bit like a kindergarten teacher forcing two kids to shake hands after a fight.
On my part, I just hope that Linux will get a real competitor to ZFS.
Without it your only two choices are to boot him out or let him stay and try to ignore him. One is overly heavy handed the other just formulates escalating toxicity.
And I think that's one of the reasons Kent got the pointy, if maladroit, end of the CoC's attention. Every time he wants to break/rearchitect an internal API, or every time he makes a submission that flagrantly goes against kernel convention, you have to navigate a dozen walls of text where Kent vents and re-re-relitigates every transgression he's endured, every minute detail of his thought process as to why he needs to break the rules because his case is special, his list of ailments and anxieties that all the pushback is causing him, etc, etc, etc. His language is frequently escalatory and he seems unable to contemplate alternatives until at the brink of someone's (frequently Linus') patience and threats of bans or having bcachefs yanked from the kernel. It's brinksmanship and he overstepped.
In short, he is the "that guy" on the list.
At the time I considered those developers were right and didn't complain. It made more careful before sending patches and commenting. But it also affected my willing to contribute with the project. I also consider that, although those devs were right, they could have expressed themselves more cordially. I don't think being that rude improves anything.
I do support the CoC committee decision and hope more projects had one.
Whereas CoC-driven development risks leading to a chilling effect where you no longer constructively argue about stuff, let alone in a passionate manner (that, admittedly, risks going the wrong side of the fence on occasion), and just let shit pile up because it's not your business to be getting the snake out of the hole and messing with a CoC Panel for it.
And this is even in the 'ideal' case where the CoC Panel has no 'political' ulterior motives. God forbid when this is not the case.
Basically, careful what you wish for.
Based on what data?
But It would surely suffice to prevent a demand for a public apology from the exasperated party who was on the right side of the argument ; or at least not before the insulted party having issued an apology for being wrong and uncooperative in the first place.
When CoC have the effect of punishing volunteer work for not being nice/polite/SFW during an argument, regardless of who was technically right, this is putting form over substance.
This is a stance that seems balanced toward corporate friendliness. But I believe that the kernel benefits more from being a community/volunteer oriented project than pandering to corporate culture of niceness over anything else.
Losing BcacheFS over this would be a shame.
And it's corporate because linux is now corporate run. And all these things make sure that no volunteer will ever take part.
I agree the last sentence by Kent was not needed, but I can totally understand his frustration.
I think it’s a loss for the users at the end on the day.
[citation needed]
In case anyone's looking for that last sentence (quoting Kent here, not my words):
> Get your head examined. And get the fuck out of here with this shit.
https://lore.kernel.org/lkml/citv2v6f33hoidq75xd2spaqxf7nl5w...
IMHO
Democracy is good governance not a dictatorship of a majority.
A benevolent dictatorship is said to be a most efficient form of government, until it ushers in a non-benevolent dictatorship.
Democracy is not perfect but relatively sustainable in that there is a peaceful mechanism for change and a means of consensus.
Small communities don’t need too many rules but in time as they grow it becomes necessary.
Reading his comment on LWN, he seems really really tired. A mandatory break doesn’t look like the worst thing which would happen to him. I don’t think he is a bad person.
In the short term Ken will have to wait for the time out to end, so a loss for sure.
On balance the future is bigger than the present so suffering today for a better future is utilitarian.
And there are a lot of sensitive folk who have been scared off of communities by what they saw. In this thread a couple have commented about the pre CoC community, that they would have contributed but for the fear of getting barked at.
As a younger dev I bailed on some IRC communities after getting weirdly threatened.
Frustration after being very patient with one’s donated time and feeling unreciprocated can lead to frayed nerves and in the short term being rude is brief and often effective - so it is very understandable that this sort of thing will arise.
Good to discuss how we handle these difficult situations of onboarding newbies without scaring some of the lurking next generation of devs.
As a headline this penalty seems harsh, but efforts were made to mediate before the committee made the ruling and proved unsuccessful.
This process is defining the future culture of the kernel code community and it is widely accepted that it should be less toxic and more welcoming and akin to what is expected in a professional context where most devs also function and also have to patiently onboard new developers.
There may be room for improvement of the process, for instance, like in many settings the burden of patient onboarding may need to fall on a community process with an onboarding ramp that doesn’t fall only on the shoulders of those accepting patches.
As a community it behooves us to step in earlier and help new devs polish their contributions before submission.
Especially if we see a fraustration brewing, step in and offer code review to the new developers, who want to contribute, but need some guidance.
Often just guidance about the right questions to ask and where and how to find the answers oneself before asking.
The eternal September doesn’t have to be so, offering to help with onboarding a new dev helps everyone.
“professional environments” have flaws - and can be as you assert dehumanisating - more so when orgs are large, and rules enforced blindly or with ‘zero tolerance’.
I meant it as a proxy for a forum where mutual respect and civility are theoretically expected.
Although in the real world not always present.
I agree that rules can potentially be overbearing and curtail free expression but also protect and nurture expression where it is suppressed by an unruly culture.
As in most things, it is difficult to find a good balance and a healthy community is self-regulating.
Reminds me a bit of this time I had FINALLY gotten someone to volunteer to help out with maintenance, and his first action was met with someone being a real jerk. I called them out on it and they started attacking me. I never replied, but I did get an "appology" from them: [paraphrased] "I'm sooo sorry... That I sent that from my work address. Please don't get me fired, I need this job."
I am worried that the trend these code of conduct implementations set in the past few years optimize for a future where development environments will be optimized for the prosperity of low-productivity, low-intelligence, high-vulnerability and highly-provocative individuals. This idea that the tone of communication may not be coupled in any way to the frustration of the correspondent is in my opinion extremely misanthropic and allows intense psychological abuse through condescension and/or playing dumb.
I don’t think it’s the CoC committee overreacting. I would reach to HR advising termination if a member of my team did this to someone in writing. This is straight up illegal in my country. If you write this to someone, you will lose if they sue. A lenient sanction and some probation seems fine for someone with a history of good contribution but doing nothing would be wrong.
I’m not sure comparing that to the NKVD is wise.
This mentality will encourage the take-over of FLOSS communities by power-grabbing psychopath types that already thrive in corporate environments.
Not sure why would anyone want that.
Personally, I would take such an insult as a signal to step away from the immediate conversation and maybe rethink it after some time, but this (admittedly very flamewar provoking and somewhat rude) way of pressing the RESET button on a conversation is understandably not tolerated in the same capacity as it might have been in the 1990s. The problem is, we haven't really replaced it with anything that's as efficient.
Instead what I got was "It'd be a real shame if you're no longer around", and other equally dismissive behavior, and considering this was a situation in which a maintainer was pushing for something that would likely have led to security vulnerabilities and was being dismissive of criticism I didn't feel that was something we could let slide.
Priorities, people.
Context matters, and also, if we're going to have standards for professional conduct they do need to be about more than just language.
We shouldn't be punching down, but we shouldn't be insulating maintainers from criticism when they're being incompetent, either.
Abusing others individually in public, but expecting a quiet word on the side about “the overall situation” when it comes to your own behavior. I hope you realize something from this.
Taking his personal struggles out of kernel development and onto Hacker News was the escalation – pointing out his hypocrisy is only trying to get people who agree with him to realize that they’re wrong.
So you want to take the power to produce taken away from the producers and coalesce it into the hands of those who do not produce for the sole purpose of controlling those who do produce.
You're literally a walking Orwell quote.
Nothing that completely breaks it, but I found at the time that the high variance on read requests for Samsung 970 series NVMe causes the filesystem to also dispatch reads of cached data to the HDDs, even when it’s fully cached.
Which predictably increases latency a lot.
Really I should make another stab at fixing that, but the whole driver is C, and I’m not good at writing flawless C. Combine that with the problem actually being hard…
(“Always read from SSD” isn’t a valid solution here.)
I have something on the back burner to start benchmarking devices at format time, that would let us start making better decisions in these situations.
Though it would be an improvement over what I saw last time I tried, sure.
static inline bool ptr_better(struct bch_fs *c,
const struct extent_ptr_decoded p1,
const struct extent_ptr_decoded p2)
{
if (likely(!p1.idx && !p2.idx)) {
u64 l1 = dev_latency(c, p1.ptr.dev);
u64 l2 = dev_latency(c, p2.ptr.dev);
/* Pick at random, biased in favor of the faster device: */
return bch2_rand_range(l1 + l2) > l1;
}
if (bch2_force_reconstruct_read)
return p1.idx > p2.idx;
return p1.idx < p2.idx;
}
If we're talking about my desktop, its current configuration is 3x 2TB NVMe (configured as zfs cache) plus 2x 12TB HDDs (mirrored). I've set sync=disabled, with transaction groups committing every 10 minutes — this is fine for my use case — so the HDDs spend most of their time spun down.
I only actually have 4TB of data on the system. It keeps growing, but the working set is probably much less than that.
Which means, it's 100% cached. A single read sent to the HDDs would have a latency of multiple seconds; absolutely catastrophic for a desktop workload. In this case _always_ using the cache _is_ the right answer, but I've been trying to think of an algorithm that would be able to do so without hardcoding it.
It's not his code that people felt hurt by, was it?
He was refusing to contribute his code according to the rules (by which everyone is meant to abide), avoiding regression testing and creating bugs.
And he certainly didn't help his case with tone deaf comments like this:
> If you're so convinced you know best, I invite you to start writing your own filesystem. Go for it.
There are no instances anyone can point to where I've caused regressions in other subsystems, in the course of developing bcachefs. I have had people introduce regressions into my code without following proper channels, though.
It's his kernel.
Changes should be in place in time for regression testing, if you cannot manage that wait for the next cycle.
Those same rules apply to everyone, and you're being called out for not only repeatedly ignoring them, but also for refusing to listen to that criticism.