[PATCH] MAINTAINERS: Clarify check-in requirements for mixed-author patches

[George Dunlap <george.dunlap@xxxxxxxxx>]

From: George Dunlap <george.dunlap@xxxxxxxxxx>

There was a question raised recently about the requriements for
checking in a patch which was originally written by one maintainer,
then picked up and modified by a second maintainer, and which they now both
agree should be checked in.

It was proposed that in that case, the following set of tags would suffice:

   Signed-off-by: First Author <...>
   Signed-off-by: Second Author <...>
   Reviewed-by: First Author <...>

The rationale was as follows:

1. The patch will be a mix of code, whose copyright is owned by the
various authors (or the companies they work for).  It's important to
keep this information around in the event, for instance, of a license
change or something else requiring knowledge of the copyright owner.

2. The Signed-off-by of the Second Author approves not only their own
code, but First Author's code; the Reviewed-by of the First Author
approves not only their own code, but the Second Author's code.  Thus
all the code has been approved by a maintainer, as well as someone who
was not the author.

In support of this, several arguments were put forward:

* We shouldn't make it harder for maintainers to get their code in
  than for non-maintiners

* The system we set up should not add pointless bureaucracy; nor
  discourage collaboration; nor encourage contributors to get around
  the rules by dropping important information.  (For instance, by
  removing the first SoB, so that the patch appears to have been
  written entirely by Second Author.)

Concerns were raised about two maintainers from the same company
colluding to get a patch in from their company; but such maintainers
could already collude, by working on the patch in secret, and posting
it publicly with only a single author's SoB, and having the other
person review it.

There's also something slightly strange about adding "Reviewed-by" to
code that you've written; but in the end you're reviewing not only the
code itself, but the final arrangement of it.  There's no need to
overcomplicate things.

Encode this in MAINTAINERS as follows:

* Refine the wording of requirement #2 in the check-in policy; such
that *each change* must have approval from someone other than *the
person who wrote it*.

* Add a paragraph explicitly stating that the multiple-SoB-approval
  system satisfies the requirements, and why.

Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxx>
---
 MAINTAINERS | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 175f10f33f..0e5eba2312 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -120,8 +120,8 @@ must be met:
 
    See below for rules on nested maintainership.
 
-2. It must have appropriate approval from someone other than the
-   submitter.  This can be either:
+2. Each change must have appropriate approval from someone other than
+   the person who wrote it.  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
@@ -150,6 +150,20 @@ 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.
 
+In the case where two people collaborate on a patch, at least one of
+whom is a maintainer -- typically where one maintainer will do an
+early version of the patch, and another maintainer will pick it up and
+revise it -- there should be two Signed-off-by's and one Acked-by or
+Reviewed-by; with the maintainer who did the most recent change
+sending the patch, and an Acked-by or Reviewed-by coming from the
+maintainer who did not most recently edit the patch.  This satisfies
+the requirement #2 because a) the Signed-off-by of the sender approves
+the final version of the patch; including all parts of the patch that
+the sender did not write b) the Reviewed-by approves the final version
+of the patch, including all patches that the reviewer did not write.
+Thus all code in the patch has been approved by someone who did not
+write it.
+
 Maintainers may choose to override non-maintainer objections in the
 case that consensus can't be reached.
 
-- 
2.38.1