linux-kernel - Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181023060059.GW32577@ZenIV.linux.org.uk>
Date:   Tue, 23 Oct 2018 07:00:59 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     NeilBrown <neil@...wn.name>
Cc:     Josh Triplett <josh@...htriplett.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        ksummit-discuss@...ts.linuxfoundation.org,
        Mishi Choudhary <mishi@...ux.com>
Subject: Re: [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 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...

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

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