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...