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
