From: Wei Liu <wei.liu2@citrix.com>
To: George Dunlap <george.dunlap@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Lars Kurth <lars.kurth@citrix.com>,
Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jan Beulich <jbeulich@suse.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2] MAINTAINERS: Clarify the meaning of nested maintainership
Date: Thu, 28 Apr 2016 11:28:20 +0100 [thread overview]
Message-ID: <20160428102820.GB20763@citrix.com> (raw)
In-Reply-To: <1461773187-18947-1-git-send-email-george.dunlap@citrix.com>
On Wed, Apr 27, 2016 at 05:06:27PM +0100, George Dunlap wrote:
> Clarify the meaning of nested maintainership.
>
> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
> ---
> 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=<EDB48431-C3EF-4461-B2D2-3AB95EA6C392@gmail.com>
>
> 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 <ian.jackson@eu.citrix.com>
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Tim Deegan <tim@xen.org>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Konrad Wilk <konrad.wilk@oracle.com>
> CC: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Lars Kurth <lars.kurth@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
> ---
> 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)
>
> -----------------------------------
> --
> 2.1.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-28 10:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-27 16:06 [PATCH v2] MAINTAINERS: Clarify the meaning of nested maintainership George Dunlap
2016-04-28 10:13 ` Jan Beulich
2016-04-28 10:28 ` Wei Liu [this message]
2016-04-28 15:49 ` Konrad Rzeszutek Wilk
2016-04-28 16:18 ` George Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160428102820.GB20763@citrix.com \
--to=wei.liu2@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=lars.kurth@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).