3 ms·
https://lore.kernel.org/linux-bcachefs/5ef2246b-9fe5-4206-acf0-0ce1f4469e6c@app.fastmail.com/ https://lore.kernel.org/linux-bcachefs/5ef2246b-9fe5-4206-ac...
by cwillu 3y ago
https://lore.kernel.org/linux-bcachefs/5ef2246b-9fe5-4206-acf0-0ce1f4469e6c@app.fastmail.com/ https://lore.kernel.org/linux-bcachefs/5ef2246b-9fe5-4206-ac...
[...]
So, without intending any particular hostility:
<puts on maintainer hat>
bcachefs's x86 JIT is:
Nacked-by: Andy Lutomirski <luto@kernel.org> # for x86
<takes off maintainer hat>
This makes me sad, because I like bcachefs. But you can get it merged
without worrying about my NAK by removing the x86 part.
[...]
https://lore.kernel.org/linux-bcachefs/dcf8648b-c367-47a5-a2b6-94fb07a68904@app.fastmail.com/ https://lore.kernel.org/linux-bcachefs/dcf8648b-c367-47a5-a2...
> No, I'm saying your concerns are baseless and too vague to address.
If you don't address them, the NAK will stand forever, or at least until a
different group of people take over x86 maintainership. That's fine with me.
I'm generally pretty happy about working with people to get their Linux
code right. But no one is obligated to listen to me.
>
>> text_poke() by itself is *not* the proper API, as discussed. It
>> doesn't serialize adequately, even on x86. We have text_poke_sync()
>> for that.
>
> Andy, I replied explaining the difference between text_poke() and
> text_poke_sync(). It's clear you have no idea what you're talking about,
> so I'm not going to be wasting my time on further communications with
> you.
No problem. Then your x86 code will not be merged upstream.
Best of luck with the actual filesystem parts!
--Andy
https://lore.kernel.org/linux-bcachefs/20230620201851.qrcabl327mrofygb@moria.home.lan/ https://lore.kernel.org/linux-bcachefs/20230620201851.qrcabl...
[...]
> >> Andy, I replied explaining the difference between text_poke() and
> >> text_poke_sync(). It's clear you have no idea what you're talking about,
> >> so I'm not going to be wasting my time on further communications with
> >> you.
>
> One more specific concern: This comment made me very uncomfortable and
> it read to me very much like a personal attack, something which is
> contrary to our code of conduct.
It's not; I prefer to be direct than passive
aggressive, and if I have to bow out of a discussion
that isn't going anywhere I feel I owe an explanation
of _why_. Too much conflict avoidance means things
don't get resolved.
And Andy and I are talking on IRC now, so things are
proceeding in a better direction.
- bigyikes 3y agoYikes, I guess I’m way too sensitive to ever be a kernel dev. Kent seems way out of line. “Direct” is one thing, telling a maintainer they have no idea what they’re talking about is another. It’s totally uncalled for. Are they trying to imitate Linus, or something? Sorry, you don’t get a license to be an asshole until you literally invent Linux.
- cwillu 3y agoDunno, having read through the rest of the thread, and knowing some of the history, I can see why some frustration leaked out. Worth noting that they were able to pretty much immediately work together after this to come up with what appears to be a good solution to satisfy everyone.
- Vogtinator 3y ago> Sorry, you don’t get a license to be an asshole until you literally invent Linux. That doesn't grant you a license either.
- coldtea 3y agoIt's a mindset from a previous era, when there were blunt thick-skinned hackers and not snowflake "I'll report it to the HR" types
- cmrdporcupine 3y agoI've worked through both eras, and I'll take the latter and enjoy the higher productivity and job satisfaction from everyone involved, thank you.
- bastawhiz 3y agoWhere I'm from, having a temper tantrum on a mailing list because you're not getting your way is what makes you the snowflake. If you don't want to follow the code of conduct, you can submit your patch to a kernel without one.
- 3y ago