Received: by 2002:ac0:aa62:0:0:0:0:0 with SMTP id w31-v6csp3069104ima; Mon, 22 Oct 2018 23:06:22 -0700 (PDT) X-Google-Smtp-Source: AJdET5dy3erdUgCbQyCu347Dj9Q8XoNcmFnxID7ackO0djDr9TcQZ3Ahiqp0zpx3bs903V4SCxyC X-Received: by 2002:a17:902:bd4a:: with SMTP id b10-v6mr11317351plx.171.1540274782801; Mon, 22 Oct 2018 23:06:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540274782; cv=none; d=google.com; s=arc-20160816; b=AEW3xRwDV/x3nyepIVV8gxU2V5k8mKTyAYElquO4o4dxOxR/Yg3FgiIilCjRSKVx00 PY29JZHfaFF1PwfEJpr5LlTTXGmOhRHKWK7F6ph8rnIXUQCGwzhCpkLKWh8ONOMKQ1sB CzrFytwbVruy+ZI2AHRuk6jNovkAEjN6o5R++ClMz6O/8TqHKxFMtIum1ttrvBx+Iyq2 qV7smdkZjWUb12obK2wii0jYVdfVhFw5q5duWr/XCqAYv0iLxLCrLRkQPZLLA8VA5rd3 469j97YhbNX6XvuPIuGgioKDhmDxlDyWWcgXv8z8mDGmDxQI3AFRxI61lutTGmZFpsX1 QBzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=+l+Ucygobr2vMhpyhjaWOQTWEwFF1ctwOTXrXaTg+g4=; b=pWetKjrgHcEhe+xZNzLY9CkECNxnRlVbdTMJv5G2QtyRpZo/bFoLrvSIaQt2MBb97N +zyOxCxLxfqLAVPJFK0/ZLKITktT6QvJa0uiPRzcglvDOodYWyQPhUXYCX+X19YCP7LN gEjv1dRJJrZ649+es4EyNU+JdDfJI3lGyqeJC5KVlTe0B8qEjb797Ej+vdyQKFWG7njC wf+xWmcYfPSICM06m+Bnpj5GZZPzw9t1WJvI2gehSXV8imZFKix6WMyYdiuVlHpVRKy0 Qp7twt3F/+oNc4A7EVwNQk1W2x9XKXgZgLmP0gkjW0zJgSzviM3E40Ab9IbR3p4vr1ar 84Rw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r68-v6si324080pfa.15.2018.10.22.23.06.06; Mon, 22 Oct 2018 23:06:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727655AbeJWOXA (ORCPT + 99 others); Tue, 23 Oct 2018 10:23:00 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:35804 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726764AbeJWOXA (ORCPT ); Tue, 23 Oct 2018 10:23:00 -0400 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1gEpkR-0004zX-KG; Tue, 23 Oct 2018 06:00:59 +0000 Date: Tue, 23 Oct 2018 07:00:59 +0100 From: Al Viro To: NeilBrown Cc: Josh Triplett , Greg Kroah-Hartman , linux-kernel , Linus Torvalds , ksummit-discuss@lists.linuxfoundation.org, Mishi Choudhary Subject: Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document Message-ID: <20181023060059.GW32577@ZenIV.linux.org.uk> References: <20181020134908.GA32218@kroah.com> <87y3ar80ac.fsf@notabene.neil.brown.name> <20181021222608.GA24845@localhost> <875zxt919d.fsf@notabene.neil.brown.name> <20181023033130.GQ32577@ZenIV.linux.org.uk> <87r2gh70ij.fsf@notabene.neil.brown.name> <20181023045247.GV32577@ZenIV.linux.org.uk> <87o9bl6xlo.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o9bl6xlo.fsf@notabene.neil.brown.name> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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...