From patchwork Wed Apr 27 16:06:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: George Dunlap X-Patchwork-Id: 8959731 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3292A9F441 for ; Wed, 27 Apr 2016 16:08:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2C5CA20219 for ; Wed, 27 Apr 2016 16:08:49 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3539F200DC for ; Wed, 27 Apr 2016 16:08:47 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avRz2-0003aU-HE; Wed, 27 Apr 2016 16:06:36 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1avRz0-0003aJ-TT for xen-devel@lists.xenproject.org; Wed, 27 Apr 2016 16:06:35 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id BC/A1-29636-A83E0275; Wed, 27 Apr 2016 16:06:34 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRWlGSWpSXmKPExsXitHSDvW7nY4V wgz8P9S2+b5nM5MDocfjDFZYAxijWzLyk/IoE1oyTa1ULbkhXTN0T3sC4ULyLkZNDQsBfYtfx I8wgNpuAnsS8419Zuhg5OEQEVCRu7zXoYuTiYBY4wiQxZ95BJpAaYQFfiaOv9oPVswioSryZv wbM5hXwkJi07wULxEw5ifPHf4LFhYBqFj84yg5RIyhxcuYTsBpmAQmJgy9eMIPskhDglvjbbT +BkWcWkqpZSKoWMDKtYlQvTi0qSy3SNddLKspMzyjJTczM0TU0MNXLTS0uTkxPzUlMKtZLzs/ dxAgMDgYg2MF4bLLzIUZJDiYlUd4lZxXChfiS8lMqMxKLM+KLSnNSiw8xynBwKEnw+j0CygkW paanVqRl5gDDFCYtwcGjJMI76wFQmre4IDG3ODMdInWKUVFKnFcXpE8AJJFRmgfXBouNS4yyU sK8jECHCPEUpBblZpagyr9iFOdgVBLmDQaZwpOZVwI3/RXQYiagxZcPyYIsLklESEk1MJruqz j025Zz6ofovAe3bZ0rRJp4ZR592m7YvXl7YvmF7BnXUvdlX3z+oDGmikfQQndWTP/p4uzqp1H K7TyKd+rU5/o8nsJh2nJg/9wzh+Q9d12unVm7/1DpAiv9kNSghUyzGKafSGc2D+/8V1jZ86zt qZHgQT72nuZeHbOYGfrem62SeQ6rKrEUZyQaajEXFScCANoazA+IAgAA X-Env-Sender: prvs=918757b19=George.Dunlap@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1461773192!36573484!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 8.34; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64551 invoked from network); 27 Apr 2016 16:06:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 27 Apr 2016 16:06:33 -0000 X-IronPort-AV: E=Sophos;i="5.24,542,1454976000"; d="scan'208";a="356825816" From: George Dunlap To: Date: Wed, 27 Apr 2016 17:06:27 +0100 Message-ID: <1461773187-18947-1-git-send-email-george.dunlap@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 X-DLP: MIA1 Cc: Lars Kurth , Keir Fraser , Tim Deegan , Ian Jackson , George Dunlap , Jan Beulich , Andrew Cooper , Wei Liu Subject: [Xen-devel] [PATCH v2] MAINTAINERS: Clarify the meaning of nested maintainership X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Clarify the meaning of nested maintainership. Signed-off-by: George Dunlap Acked-by: Jan Beulich Acked-by: Wei Liu Acked-by: Konrad Rzeszutek Wilk --- We had a discussion about the meaning of nested maintainership at the recent Xen Hackathon. The notes of that meeting can be found on this list [1]. No decision is official until discussed on this list, so consider this patch the official proposal for this change, and object or ask for clarification accordingly. Compared to v1, there is one change that is worth pointing out: The claim that THE REST consists of all committers. This is the case at the moment, but this change would codify that this is an invariant we intend to keep going forward. The advantage of this is that the dispute resolution mentioned in this patch for maintainers who can't agree lines up directly with the fall-back for broader community issues upon which we can't reach consensus. [1] marc.info/?i= Changes in v2: - fixed spelling of "maintainer" - fixed path of multi.c - clarified that the resolution by REST would be by *majority* vote - Asserted that The REST consists of all committers CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan CC: Wei Liu CC: Konrad Wilk CC: Andrew Cooper CC: Lars Kurth --- MAINTAINERS | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5af7a0c..9057f96 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -94,6 +94,40 @@ Descriptions of section entries: printk, pr_info or pr_err One regex pattern per line. Multiple K: lines acceptable. + +The meaning of nesting: + +Many maintainership areas are "nested": for example, there are entries +for xen/arch/x86 as well as xen/arch/x86/mm, and even +xen/arch/x86/mm/shadow; and there is a section at the end called "THE +REST" which lists all committers. The meaning of nesting is that: + +1. Under normal circumstances, the Ack of the most specific maintainer +is both necessary and sufficient to get a change to a given file +committed. So a change to xen/arch/x86/mm/shadow/multi.c requires the +the Ack of the xen/arch/x86/mm/shadow maintainer for that part of the +patch, but would not require the Ack of the xen/arch/x86 maintainer or +the xen/arch/x86/mm maintainer. + +(A patch of course needs acks from the maintainers of each file that +it changes; so a patch which changes xen/arch/x86/traps.c, +xen/arch/x86/mm/p2m.c, and xen/arch/x86/mm/shadow/multi.c would +require an Ack from each of the three sets of maintainers.) + +2. In unusual circumstances, a more general maintainer's Ack can stand +in for or even overrule a specific maintainer's Ack. Unusual +circumstances might include: + - The patch is fixing a high-priority issue causing immediate pain, + and the more specific maintainer is not available. + - The more specific maintainer has not responded either to the + original patch, nor to "pings", within a reasonable amount of time. + - The more general maintainer wants to overrule the more specific + maintainer on some issue. (This should be exceptional.) + - In the case of a disagreement between maintainers, THE REST can + settle the matter by majority vote. (This should be very exceptional + indeed.) + + Maintainers List (try to look for most precise areas first) -----------------------------------