|
|
Subscribe / Log in / New account

Conflict over a code

Conflict over a code

Posted Mar 21, 2015 4:38 UTC (Sat) by marcH (subscriber, #57642)
In reply to: Conflict over a code by nevets
Parent article: Conflict over a code

> The biggest insults I have seen on LKML come from a maintainer that is grumpy. You make maintainers less grumpy and they will respond a bit nicer.

Maintainers are grumpy when they care too much and have too much time to waste. Ignorance (of people not paying attention the first time) is much stronger and more effective than grumpiness and it does leave anything to complain about.

This says it better: http://xkcd.com/386/


to post comments

Conflict over a code

Posted Mar 21, 2015 14:07 UTC (Sat) by nevets (subscriber, #11875) [Link] (3 responses)

You obviously have no clue what you are talking about, and that cartoon that you linked to proves it. That cartoon is more of an example of Social Justice Warriors that complain about Linus being too rude than about grumpy maintainers.

Maintainers are grumpy for the exact opposite reason you mention. They have too little time on their hands. They are overworked and are struggling with some technical problem that is taking much longer to solve than expected. Then a patch comes in that is broken and the author refuses to listen to why it is broken. That maintainer doesn't have time to hand hold the author of the patch and sometimes gets nasty with the replies. Stress makes one grumpy, not having too much time on your hands.

I'm not saying it is right that a grumpy maintainer sends someone a nasty email. But maybe the solution is to help them be less grumpy, and they may be nicer in their replies. But your comment is totally off the mark, and shows that you have no idea about kernel maintainership.

Conflict over a code

Posted Mar 22, 2015 5:42 UTC (Sun) by marcH (subscriber, #57642) [Link] (2 responses)

> They are overworked and are struggling with some technical problem that is taking much longer to solve than expected. Then a patch comes in that is broken and the author refuses to listen to why it is broken.

... then some maintainers strangely keep wasting their time reading such patches and writing nasty replies to their author, instead of just inserting his name in their kill file. Too much care doing more harm than good.

Thanks for not just your violent agreement, but also - and even better - a similar demonstration here again.

> But your comment is totally off the mark, and shows that you have no idea about kernel maintainership.

My comment has nothing specific to the kernel; it applies anywhere. Violent agreement number 2.

Conflict over a code

Posted Mar 22, 2015 13:30 UTC (Sun) by nevets (subscriber, #11875) [Link] (1 responses)

> then some maintainers strangely keep wasting their time reading such patches and writing nasty replies to their author, instead of just inserting his name in their kill file. Too much care doing more harm than good.

When someone submits a patch to code you maintain, it is your obligation to send a reply. Reviewing patches is part of the maintainers job. Ideally, you review the patch and the author listens to you and corrects the mistakes. But when you "waste" time reviewing a patch and the author ignores your comments that tends to piss the maintainer off. I'm not saying it is right to reply nasty, but it still requires a reply. And the "kill file" is actually the biggest insult you can do to a patch submitter.

> My comment has nothing specific to the kernel

Then why bother commenting on this thread at all? The topic is about the "Code of Conflict" that was added for kernel development. I'm specifically talking about that document and why it was added and why kernel maintainers are grumpy and post nasty replies. What are you talking about?

> it applies anywhere. Violent agreement number 2.

I would agree if we were talking about social media and news article comments, as those are all about opinions and not technical discussions like kernel development is. But this is not about social media, it's about discussing technical issues in a polite manner that people on both sides fix the problems at hand.

I think we are in violent agreement that you do not understand kernel maintainership.

Conflict over a code

Posted Mar 23, 2015 6:05 UTC (Mon) by marcH (subscriber, #57642) [Link]

> When someone submits a patch to code you maintain, it is your obligation to send a reply. [...] I'm not saying it is right to reply nasty, but it still requires a reply.

Up to a point (the point of nastiness)

> And the "kill file" is actually the biggest insult you can do to a patch submitter.

It's not nice but it's certainly not an "insult".

Anyway the "kill file" was just a image to try to get the original point across: in various projects all over the world, public and private, over-busy maintainers and tech leads have to manage their time and prioritize high value contributions over hand-holding / spoon-feeding, neglecting the latter and treating it with just silence because of lack of time. Such a neglect is neither ideal nor desirable, yet it happens constantly and causes orders of magnitude less drama than swearing and actual insults, never makes any headline in Hacker News or anywhere else, and does not require any Code of Whatever. It's just basic meritocracy and it just works; routinely.

> Then why bother commenting on this thread at all? [..] I'm specifically talking about that document and why it was added and why kernel maintainers are grumpy and post nasty replies.

Because the kernel community is quite clearly not as special as you seem to think it is, it's made of almost normal human beings, and any drama happening to it is barely different from what happens and happened anywhere else, including in ages-old literature - or brand new like XKCD.

> I think we are in violent agreement that you do not understand kernel maintainership.

Repeating this is not going to make it more relevant (afraid relevance is not the main intention behind the repetition).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds