[Xen-devel] add_maintainers.pl issues / "canonical" subject prefixes for CI v2 (was Re: [PATCH] create-diff-object: more precisely identify .rodata sections)

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

+Ross 
+ Doug

On 19/09/2019, 10:30, "Julien Grall" <julien.grall@xxxxxxx> wrote:

    Hi Lars,
    
    On 18/09/2019 13:14, Lars Kurth wrote:
    > 
    > 
    > On 18/09/2019, 12:15, "Julien Grall" <julien.grall@xxxxxxx> wrote:
    > 
    >      Hi Ian,
    >      
    >      On 18/09/2019 11:41, Ian Jackson wrote:
    >      > Julien Grall writes ("Re: [PATCH] create-diff-object: more 
precisely identify .rodata sections"):
    >      >> On 18/09/2019 10:52, Wieczorkiewicz, Pawel wrote:
    >      >>> $ scripts/./add_maintainers.pl -d ~/git/livepatch-build-tools
    >      >>
    >      >> '-d' only tells you where the patches files are. The script will 
look up for the
    >      >> MAINTAINERS file in the current directory.
    >      >
    >      > Hmmm.  I wonder if we could detect this situation somehow.  This 
will
    >      > be a common user error I think.
    >      I think it would be possible for patch modifying file. We could 
check whether
    >      the file modified exist in the repo. Though, I am not sure how 
difficult it
    >      would be to implement.
    >      
    > That might be doable, but won't be easy as I will essentially need to 
parse the patch
    > And it won't be reliable.
    > 
    > The only workable way of doing this may be to have a strong convention
    > that requires to use the [REPONAME PATCH] via --subject-prefix when 
generating the
    > patch and for add_maintainers.pl to verify this somehow based on the 
current
    > directory and the patches.
    > 
    > We already have strong conventions in some cases, e.g. for OSSTEST we 
always use
    > [OSSTEST PATCH]. This would potentially be helpful for the CI loop plans 
aso.
    > 
    > Assuming there is a git config setting for --subject-prefix then this 
could be made
    > to work. I could add a section under [1] to document the convention with 
the
    > appropriate git command. We could include a script (e.g. 
xen.git:scrips/git-setup)
    > which does this based on the repo name automatically.
    
    I saw a conversation on IRC about this. But it is not clear if there was 
any 
    conclusion?

Ian was going to write down what we discussed
    
    My only slight concern about tagging by default is the length of the 
subject, 
    when directly receiving from xen-devel (i.e. not CCed), the subject is 
already 
    [xen-devel][PATCH XX/XX]. I am assuming the tag will not be dropped so it 
will 
    appear on the mailing list. For repo such as LIVEPATCH-BUILD, this would 
end up 
    to lengthy prefix.

That is true: I think we do need to have a formal discussion with vote about 
this at some point. 

And we can certainly shorten some of those "canonical" subject prefixes. 
But having gone back to the early patches posted for LIVEPATCH-BUILD by Konrad 
and Ross, they were either
[LIVEPATCH-BUILD-TOOLS] or [LIVEPATCH-BUILD-TOOLS PATCH]

My view at this stage, is that I am merely documenting existing conventions 
The exception is "XEN PATCH"

For people who are just starting to read this conversation, see
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Settings_that_help_save_you_time
* 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Subject_Prefix 
which I added yesterday

We do need to solve this somehow for two reasons:
1. Fool proofing add_maintainers.pl tool [although this is relatively minor]
2. More importantly we need to support the CI v2 capability (aka triggering 
tests for patches posted to xen-devel@)

On 1: Ian had an idea, which I think I understood correctly, but am not 100% 
sure. So waiting for him to write it down

On 2: We need a way to identify which tree a patch or patch series is for, such 
that any CI infra can perform the right action, in light of
* QEMU, LINUX, ... patches are posted to xen-devel@ today
* Patches for multiple xen-repos are posted to xen-devel@ today

But maybe we should move this into a new thread. In the meantime I changed the 
subject line

Lars

    

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