lkml.org 
[lkml]   [2018]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
On Tue, Oct 23 2018, Al Viro wrote:

> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even less now.
>> > What are you proposing? Duopoly? How do you deal with disagreements? Fork?
>> > Revert wars?
>>
>> We already have team-maintainership arrangements - doing the same thing
>> at the top level should not be that hard to imagine.
>>
>> It really about "saying" no. I suspect all members of a team would come
>> to much the same decision about any given patch, but they might "say" it
>> differently. One might say "anyone who wrote this should be
>> lobotomised", and the other might say "I see what you are trying to do,
>> but the approach won't work - go look at how we handle XXXX, they have a
>> similar problem". Neither will accept the patch, and they will probably
>> both accept it after certain changes. But when one of them is having a
>> bad day, I would like people to have the explicit opportunity to ignore
>> them and talk to the other. Yes, they'll still get "no" twice, but they'll
>> also get something approaching sane review least once.
>
> You still have not answered the question I've asked - what to do in case of
> real disagreements, seeing that "pass it to Linus for final decision" obviously
> doesn't work here. And while we are at it, what to do in case when "they"
> _agree_ that patch is unsalvagable? I'm quite sure that you can think of
> examples of such...

Sorry, things easily get lost in such a wide ranging conversation.
Handling of real disagreements is not my problem, unless I am a member
of the maintainership team. We have maintainership teams which appear
to work, so they provide an existence-proof that something can be
achieved.

Were I to have an opportunity to be part of a maintainership team, I
would probably base any internal agreement necessary on two principles.
1/ People on the team are reasonably competent, and aren't going to
commit anything that all controversial without being quite confident.
I would choose to trust.

2/ We commit bad patches often, and when we realize, we fix them. You
and I have both been on both sides of that. We (the community)
even commit quite large mistakes (devfs, control-groups) and the world
doesn't end. Accepting imperfection is a key part of Linus' pragmatic
approach, and a key part of the success of Linux.

If they agree that the patch is unsalvagable, then they say so -
politely and with reasons. It is a right-of-review, not a
right-of-success.


>
> BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to see
> details - got to be interesting...

Sorry, it was a deliberately ficticious example.

Thanks for showing an interest, it is more than a lot of people are
doing.
NeilBrown

>
> [1] on kernel development lists, that is - I can think of examples in e.g.
> NANAE circa '98 or so regarding the SGI employees responsible for sendmail
> setup they used to ship in IRIX, but that was more of a possible explanation
> of the reasons rather than suggested remedy...
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-10-23 22:46    [W:0.130 / U:2.840 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site