From: Ian Jackson Date: Mon, 12 Apr 2021 10:13:15 +0000 (+0100) Subject: MAINTAINERS: Belatedly update for this being a stable branch X-Git-Tag: archive/raspbian/4.14.2+25-gb6a8c4f72d-2+rpi1^2~47^2~34 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=1ebc077a5608bd8eff7e6401696f16c9a266b73f;p=xen.git MAINTAINERS: Belatedly update for this being a stable branch Signed-off-by: Ian Jackson --- diff --git a/MAINTAINERS b/MAINTAINERS index e374816755..4b72a6adae 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -54,6 +54,15 @@ list. Remember to copy the appropriate stable branch maintainer who will be listed in this section of the MAINTAINERS file in the appropriate branch. +The maintainer for this branch is: + + Jan Beulich + +Tools backport requests should also be copied to: + + Ian Jackson + + Unstable Subsystem Maintainers ============================== @@ -104,89 +113,6 @@ Descriptions of section entries: xen-maintainers- - Check-in policy - =============== - -In order for a patch to be checked in, in general, several conditions -must be met: - -1. In order to get a change to a given file committed, it must have - the approval of at least one maintainer of that file. - - 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. - - See below for rules on nested maintainership. - -2. It must have appropriate approval from someone other than the - submitter. This can be either: - - a. An Acked-by from a maintainer of the code being touched (a - co-maintainer if available, or a more general level maintainer if - not available; see the secton on nested maintainership) - - b. A Reviewed-by by anyone of suitable stature in the community - -3. Sufficient time must have been given for anyone to respond. This - depends in large part upon the urgency and nature of the patch. - For a straightforward uncontroversial patch, a day or two may be - sufficient; for a controversial patch, a week or two may be better. - -4. There must be no "open" objections. - -In a case where one person submits a patch and a maintainer gives an -Ack, the Ack stands in for both the approval requirement (#1) and the -Acked-by-non-submitter requirement (#2). - -In a case where a maintainer themselves submits a patch, the -Signed-off-by meets the approval requirement (#1); so a Review -from anyone in the community suffices for requirement #2. - -Before a maintainer checks in their own patch with another community -member's R-b but no co-maintainer Ack, it is especially important to -give their co-maintainer opportunity to give feedback, perhaps -declaring their intention to check it in without their co-maintainers -ack a day before doing so. - -Maintainers may choose to override non-maintainer objections in the -case that consensus can't be reached. - -As always, no policy can cover all possible situations. In -exceptional circumstances, committers may commit a patch in absence of -one or more of the above requirements, if they are reasonably -confident that the other maintainers will approve of their decision in -retrospect. - - 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. - -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)