Re: Questions related to the analysis of the Xen mailing lists

[Ian Campbell <ian.campbell@citrix.com>]

On Mon, 2015-09-07 at 17:11 +0100, Lars Kurth wrote:
> Daniel,
> 
> I am assuming it is OK to post this one to the devel-list, to get extra
> answers.
> 
> > On 7 Sep 2015, at 16:19, Daniel Izquierdo <dizquierdo@bitergia.com>
> > wrote:
> > 
> > Hi Lars,
> > 
> > I promise this is the last email ;).
> > 
> > We've found that there are several flags launched by different
> > developers depending on the status of the patchset.
> > 
> > By 'flag' I mean comments like 'Signed-off-by: xxx@xxx'.
> > 
> > However, I think we do not fully understand all of them. I'm listing
> > all
> > of them below adding some comments. Please, would you mind double
> > checking this and adding others that we may have missed? Thanks in
> > advance!.
> > 
> > * Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>: This is the author of
> > the patch
> 
> Correct

This isn't 100% accurate (for Linux or Xen).

The author of a patch is the person listed in the From header or pseudo-header. The pseudo-header is a fake From: header at the top of the message body, which is used when somebody forwards a patch written by someone else. and overrides the emails From header. This is what becomes the "Author" field in the git metadata.

For example see
http://mid.gmane.org/<1434375399-19107-3-git-send-email-wei.liu2@citrix.com>
which is a patch where I am the author but Wei was resending it as part of his larger series. Here the mail is "From: Wei" but has a "From: Ian" pseudo-header.

The first S-o-b would usually also be the author but there are two caveats here:

Firstly a mail may have multiple S-o-b lines, reflecting the path which a patch has taken through different people, i.e. under 3(b) or 3(c) in the DCO. Arguably in the mail above Wei should have added his S-o-b when he forwarded it.

Secondly in (very) rare cases the S-o-b may be by other than the author. This could happen e.g. if two people work for the same company which owns the copyright on both their work and one person writes a patch and a second submits it and asserts they have the right to do so (i.e. that the have the right to submit works owned by the company under the appropriate license). This is pretty unusual (I'm not sure I've ever actually seen it) and normally there would be a S-o-b from the original author, but that isn't always possible (maybe they are gone).

> See https://www.kernel.org/doc/Documentation/SubmittingPatches section 11

AKA The Developers Certificate of Origin or DCO.

It also lives at http://developercertificate.org/ where it is unencumbered
by the rest of the Linux SubmittingPatches and is therefore a better
reference when talking about projects other than Linux.

> - we have exactly the same requirement in Xen

> 
> > * Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> : This is the
> > reviewer of the patch

NB: it is _a_ reviewer, there may be several.

> Correct
> Although the definition is more loose compared to 
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> 
> > * Acked-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>: Is this another
> > reviewer of the patch, but with more privileges?
> 
> Correct
> Although the definition is more loose compared to 
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> 
> One of the things I would like to find out, is whether we do have a lot
> of cases where there are
> a) comments
> b) changes
> for a patch after it was marked Acked-by and whether there are any
> frequent patterns.  
> 
> > * Release-acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>: Is this the
> > developer
> > in charge of merging the code into master?
> 
> That means the release manager signals that this particular patch can be
> committed. It is normally only relevant during times of a feature freeze.
> In other words, a patch can be acked (because it's technical sound), but
> it might not be appropriate to be committed (too much risk vs too little
> gain). 
> 
> I think you should just ignore that tag when counting contributions. But
> it may be worthwhile including it in the model.

FWIW when I commit I often don't bother adding this tag if it was given,
since I think it is only of ephemeral usefulness. I don't remove it if it
is already in the patch though and I know other committers do add it.

I agree that it should be ignored.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel