Re: [Xen-devel] [PATCH v4] MAINTAINERS: Add explicit check-in policy section

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.01.2020 16:04, George Dunlap wrote:
> The "nesting" section in the MAINTAINERS file was not initially
> intended to describe the check-in policy for patches, but only how
> nesting worked; but since there was no check-in policy, it has been
> acting as a de-facto policy.
> 
> One problem with this is that the policy is not complete: It doesn't
> cover open objections, time to check-in, or so on.  The other problem
> with the policy is that, as written, it doesn't account for
> maintainers submitting patches to files which they themselves
> maintain.  This is fine for situations where there are are multiple
> maintainers, but not for situations where there is only one
> maintainer.
> 
> Add an explicit "Check-in policy" section to the MAINTAINERS document
> to serve as the canonical reference for the check-in policy.  Move
> paragraphs not explicitly related to nesting into it.
> 
> While here, "promote" the "The meaning of nesting" section title.
> 
> DISCUSSION
> 
> This seems to be a change from people's understanding of the current
> policy.  Most people's understanding of the current policy seems to be:
> 
> 1.  In order to get a change to a given file committed, it must have
> an Ack or Review from at least one *maintainer* of that file other
> than the submitter.
> 
> 2. In the case where a file has only one maintainer, it must have an
> Ack or Review from a "nested" maintainer.
> 
> I.e., if I submitted something to x86/mm, it would require an Ack from
> Jan or Andy, or (in exceptional circumstances) The Rest; but an Ack from
> (say) Roger or Juergen wouldn't suffice.
> 
> Let's call this the "maintainer-ack" approach (because it must have an
> ack or r-b from a maintainer to be checked in), and the proposal in
> this patch the "maintainer-approval" (since SoB from a maintainer
> indicates approval).
> 
> The core issue I have with "maintainer-ack" is that it makes the
> maintainer less privileged with regard to writing code than
> non-maintainers.  If component X has maintainers A and B, then a
> non-maintainer can have code checked in if reviewed either by A or B.
> If A or B wants code checked in, they have to wait for exactly one
> person to review it.
> 
> In fact, if B is quite busy, the easiest way for A really to get their
> code checked in might be to hand it to a non-maintainer N, and ask N
> to submit it as their own.  Then A can Ack the patches and check them
> in.
> 
> The current system, therefore, either sets up a perverse incentive (if
> you think the behavior described above is unacceptable) or unnecessary
> bureaucracy (if you think it's acceptable).  Either way I think we
> should set up our system to avoid it.
> 
> Other variations on "maintainer-ack" have been proposed:
> 
> - Allow maintainer's patches to go in with an R-b from "designated
>   reviewers"
> 
> - Allow maintainer's patches to go in with an Ack from more general
>   maintainer
> 
> Both fundamentally make it harder for maintainers to get their code in
> and/or reviewed effectively than non-maintainers, setting up the
> perverse incentive / unnecessary bureaucracy.
> 
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Albeit I guess this is rather something which needs voting on.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel