The kernel's code of conflict [LWN.net]

The kernel's code of conflict

Posted Mar 12, 2015 16:06 UTC (Thu) by mstsxfx (subscriber, #41804)
Parent article: The kernel's code of conflict

First of all I want to mention that I do not have a problem with the wording of the document. I am not convinced it is really needed or useful but that is hard to judge.

What I find disturbing, though, is the way _how_ it was merged. I do not seem to be able to find any reference to a public discussion nor the patch posted anywhere before it has been merged and even the pull request hasn't been posted anywhere public it seems. Or maybe I am just asking google wrong questions.

I thought that all the patches should be posted public so that people have chance to comment on. Documentation/SubmittingPatches says:
"
6) Select your CC (e-mail carbon copy) list.

Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.

Other kernel developers besides Linus need to be aware of your change,
so that they may comment on it and offer code review and suggestions.
linux-kernel is the primary Linux kernel developer mailing list.
"

So it all seems like the discussion has been avoided intentionally which is kind of sad and really not a good precedence.

Michal Hocko

to post comments

The kernel's code of conflict

Posted Mar 13, 2015 1:11 UTC (Fri) by neilbrown (subscriber, #359) [Link] (3 responses)

You have a point, but I cannot imagine a public discussion on this sort of patch being at all useful. It is not like code that can - to some extent - be objectively measured. You'd end up with endless bike-shedding and little progress.

I see the patch as essentially a policy statement by the TAB. It says "We want to hear your concerns as will endeavour to respond to them". As such, it seems reasonable that the TAB are the only ones with input.

The non-TAB individuals who gave their 'Acked-by', didn't get to discuss or revise the wording. All we got was the opportunity to publicly support the TAB in this initiative.

The kernel's code of conflict

Posted Mar 13, 2015 1:47 UTC (Fri) by viro (subscriber, #7872) [Link]

Yes, we were. My reasons for not ACKing that thing (and I'm actually surprised that it wasn't the most common reaction): no examples whatsoever of TAB actually doing that kind of mediation - unsurprisingly, since it hadn't done any yet.

<viro> FWIW, what makes me somewhat nervous about it is that it covers everything from "... and that address routes to /dev/null (and I endorse that)" to "... and a crew with baseball bats will descend on the offender to explain the error of his ways (and I endorse that)"
<viro> thus the question about the examples of previous mediations in such situations

which got basically, "understood, but we really have no examples yet" in response. I don't like signing off on something _that_ vague - not because I expect either of the variants I've mentioned to materialise, but because there's a whole lot in between and I won't blindly endorse the entire range.

My reading of that thing is "Not everything is a flame, but if you feel real bad - send complaints to $ADDRESS. Try to trigger fewer complaints". What's missing is any information about the handling of such complaints - not just how anything could or could not be enforced, but much more basic "how does TAB end up dealing with such cases". And consisting of well-meaning folks doesn't cover it, obviously.

No examples to judge by - no ACK...

The kernel's code of conflict

Posted Mar 13, 2015 13:33 UTC (Fri) by mstsxfx (subscriber, #41804) [Link] (1 responses)

> You have a point, but I cannot imagine a public discussion on this sort of
> patch being at all useful. It is not like code that can - to some extent -
> be objectively measured. You'd end up with endless bike-shedding and
> little progress.

Yes this is a topic with a high flamewars potential. But that alone is not a reason for doing things behind the scenes IMO. Once there would be a sufficient Acked-bys then the patch would be justified for merging. Besides that any NAK would have to be justified properly as well ("I do not think this would help" argument doesn't fall into that category).

It would be quite natural to ask whether all changes to this document are going to be handled in the same way because by the flmatory nature will not change most probably.

> The non-TAB individuals who gave their 'Acked-by', didn't get to discuss
> or revise the wording. All we got was the opportunity to publicly
> support the TAB in this initiative

TAB is a technical advisory AFAIK and my perception is that issues mentioned by the document are not technical by definition.

The kernel's code of conflict

Posted Mar 14, 2015 5:28 UTC (Sat) by neilbrown (subscriber, #359) [Link]

> TAB is a technical advisory AFAIK and my perception is that issues mentioned by the document are not technical by definition.

How would you define "technical" then? Is there no technique in interacting effectively with other people?