Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Lars Kurth <lars.kurth@citrix.com>]

Added Paul Durrant

On 16/08/2019, 12:17, "Anthony PERARD" <anthony.perard@citrix.com> wrote:

    On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
    > Hi Lars,
    > 
    > On 16/08/2019 11:42, Lars Kurth wrote:
    > > Unikraft repos follow the same syntax as xen.git with the
    > > following exceptions:
    > > * MAINTAINERS files are called MAINTAINERS.md
    > > * M: ... etc blocks are preceded by whitespaces for rendering as
    > >    markup files
    > 
    > There is an other difference. The "fallback" category is "UNIKRAFT GENERAL"
    > and not "THE REST".
    > 
    > > 
    > > This change will
    > > - load MAINTAINERS.md if MAINTAINERS is not present
    > > - deal with indented M: ... blocks
    > 
    > One process question. Does it mean Unikraft folks will have to checkout Xen
    > in order to use {add, get}_maintainers.pl? If so, would it make sense to
    > have add_maintainers.pl and script_maintainers.pl in a separate repo that
    > can be added as submodule?
    
    Shouldn't instead the Unikraft repo have it's one get_maintainers
    script? xen.git's script doesn't needs to have support for every single
    repo available on earth and Unikraft is a different project anyway.
    
    Usually, projects with a MAINTAINERS file have there own get_maintainers
    script.
    
Well: Unikraft is part of the Xen Project. 

When I started to clean up the contribution docs it became apparent that
there is a lot of inconsistency. Ideally our contribution guide [0] would apply 
to pretty much *all* sub projects which use a mailing list based workflows

Consistency makes life for developers and also newcomers much easier. And the 
number of new devs who seem to trip over inconsistencies between projects are 
quite large (we had 3  cases in 3 weeks which I noticed).

If we start improving our CI infrastructure (which we are), it would be nice if other 
sub projects had the possibility to easily hook into it or replicate it. But that does require 
some consistency.

That's why I submitted [1] and [2]

Sub-projects with mail based workflows
1: Hypervisor
2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
3: Windows PV Drivers - which will require changes to their MAINTAINERS file 
4: Unikraft

Supporting 1 - 3 should be straightforward because you would almost always
have xen.git checked out. 4 is more different.

When I did [1] supporting Unikraft looked quite straightforward, which is
why I submitted this patch. But, given the issues Julien highlighted maybe that 
is not the case. 

I think for now, maybe we should focus on 1 - 3 and let the Unikraft devs decide 
how to approach this. Then we can revisit the question of where to store these
scripts. For now, I think requiring to have xen.git checked out is OK.

Regards
Lars

[0] https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches     
[1] https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01575
[2] https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01581


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