Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl 
/ add_maintainers.pl scripts to be called outside of xen.git"):
> On Fri, 23 Aug 2019, Lars Kurth wrote:
> > Hi all. I would like to get this resolved and was looking for 
> > opinions. The thread is about enabling usage of get_maintainer.pl / 
> > add_maintainers.pl on sister repositories for xen.git, such as 
> > xtf.git, osstest.git, mini-os.git, ... to have a consistent tools story 
> > and make patch submission for newcomers easier. We have 
> > several options:
> > 
> > 1) Warn if the tools are applied outside the Xen tree
> > Julian felt this is likely confusing
> > 
> > 2) Do not warn under some conditions
> > 2.1) Use THE REST as identifier to avoid the warning
> > Cons: Warning would disappear because Linux and QEMU also have THE REST 
> > This may not be an issue as both MAINTAINERS files follow the same format
> > However, there may be subtle differences in behaviour for unusual options 
> > for the get_maintainer.pl script as we have not been tracking all changes
> > 
> > 2.2) Introduce a unique identifier in MAINTAINERS
> > This would imply introducing a unique identifier for xen related
> > MAINTAINER files
> > Pros: More accurate
> > Cons: Pollutes file format

I think the "Con" for 2.2 is very minor indeed.

> Any of these options are OK, really. Aside from the other subprojects, I
> think one interesting case to consider is when a user calls
> get_maintainer.pl on tools/qemu-xen-dir, which should return a warning
> or error because that's QEMU, not Xen.
> 
> So, I think it would be best to go with 2.2) introducing a new tag to
> distinguish the Xen MAINTAINERS file from the QEMU MAINTAINERS file, so
> that we can properly return a warning for tools/qemu-xen-dir, but at the
> same time it could work fine for mini-os.git.

I agree that 2.2 is the best answer.  I would be content with any of
the above options.

Ian.

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