Re: [Xen-devel] Questions related to the analysis of the Xen mailing lists

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel