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

The kernel's code of conflict

Posted Mar 13, 2015 1:11 UTC (Fri) by neilbrown (subscriber, #359)
In reply to: The kernel's code of conflict by mstsxfx
Parent article: The kernel's code of conflict

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.

to post comments

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?