Re: Followup of yesterday's design session "refactoring the REST"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.07.2020 07:56, Jürgen Groß wrote:
> Yesterday's design session at Xen Developer Summit "Hypervisor Team: .."
> had one topic regarding whether we should find specific maintainers of
> all the files currently assigned to "THE REST" in order to lower the
> amount of reviews for those assigned to be "THE REST" maintainers.
> 
> Modifying the MAINTAINERS file adding "REST@x.y" as REST maintainer
> and running the rune:
> 
> git ls-files | while true; do f=`line`; [ "$f" = "" ] && exit; \
> echo $f `./scripts/get_maintainer.pl -f $f | awk '{print $(NF)}'`; \
> done | awk '/REST/ { print $1}'
> 
> shows that basically the following files are covered by "THE REST":
> 
> - files directly in /
> - config/
> - most files in docs/ (not docs/man/)
> - misc/ (only one file)
> - scripts/
> - lots of files in xen/common/
> - xen/crypto/
> - lots of files in xen/drivers/
> - lots of files in xen/include/
> - xen/scripts/
> - some files in xen/tools/
> 
> I have attached the file list.
> 
> So the basic idea to have a "hypervisor REST" and a "tools REST"
> wouldn't make a huge difference, if we don't assign docs/ to "tools
> REST".
> 
> So I think it would make sense to:
> 
> - look through the docs/ and xen/include/ files whether some of those
>    can be assigned to a component already having dedicated maintainers
> 
> - try to find maintainers for the other files, especially those in
>    xen/common/ and xen/drivers/ (including the related include files, of
>    course)

At least for files in xen/common/ I think it was really intentional
that they - as core hypervisor files - fall under THE REST. We could
of course have a "Core Hypervisor" (or so) group, which would already
...

> - if any of the REST maintainers doesn't want to receive mails for a
>    group of the remaining REST files split the REST maintainers/files up
>    accordingly

... allow moving some into this direction.

For files under xen/drivers/ not currently covered by other entries it
may indeed be (more) feasible to find individual maintainers.

Jan