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

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

[Lars Kurth]

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
See https://www.kernel.org/doc/Documentation/SubmittingPatches section 11 - we have exactly the same requirement in Xen

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

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.

> * Reported-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>: Is this the
> developer that reported the issue?

See https://www.kernel.org/doc/Documentation/SubmittingPatches - section 13. Use is informal right now. We don't require it to be used.

> 
> * Tested-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>: I guess this is a
> tester, but this does not take place that often.

See https://www.kernel.org/doc/Documentation/SubmittingPatches - section 13. Use is informal right now. We don't require it to be used.

> 
> Then, we have also noticed some variations such as:
> 
> * Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, with Konrads
> suggestion fixed.

This is common practice when something out of the ordinary happens and is a way to highlight it 

> Are you aware of extra 'flags'?

All the ones in https://www.kernel.org/doc/Documentation/SubmittingPatches can turn up occasionally, such as suggested-by:, fixes:, ... but these are rare

> In addition to this, we have also noticed several ways to identify a
> patch serie, but pretty similar:
> 
> * [PATCH v0 2/15]
> * [PATCH v0 02/15]
> * [PATCH v1 2 of 15]

I think probably 90% will be covered by the canonical form, with some slight variants. Another common variant is [RFC PATCH ...] with the RFC being dropped eventually.

Is there usually enough meta-information to map all the patches into a series?

> Given that this process is becoming with some probability more and more
> automated, we're in first place retrieving info for the last year, and
> then expanding the analysis for the rest of the previous years. This
> should help to understand the issue nowadays and then easily escalate
> the problem.
> 
> Regards,
> Daniel.
> 
> 
> 
> --
> Daniel Izquierdo Cortazar, PhD
> Chief Data Officer
> ---------
> "Software Analytics for your peace of mind"
> www.bitergia.com
> @bitergia
> 


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

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

[Ian Campbell]

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