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

[Jürgen Groß <jg@xxxxxxxxx>]

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)

- 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

Thougts?


Juergen

Attachment: rest.txt
Description: Text document