Dear Ole,
That makes sense to me. We have a few problems to address:
1. Patches not being reviewed in a timely fashion
2. Committers spending too much time reviewing patches
3. Committers reviewing patches outside their area of expertise
4. Inability to filter code review request emails from general chit-chat,
contributing to (1).
How about this?
O Based on the set of files / directories involved in a patch, gerrit
automatically adds reviewers
O Email patch review requests w/ subject lines of the form [CODE-REVIEW] or
some such
O Send email "to" the area owner(s), "cc" committers [who should know when
folks are unavailable, etc.]
O Area owners score patches.
O If they're also committers, feel free to +2.
O Otherwise, email committers when satisfied to ensure timely merges
We know that gerrit can automatically add reviewers (see also "fd.io JJB").
This scheme depends on identifying folks that we trust to enforce a certain
level of "truth, justice, and the right way," but it should help a lot in terms
of our current committer scaling problem.
Thoughts?
Thanks... Dave
-----Original Message-----
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Ole Troan
Sent: Wednesday, December 21, 2016 7:18 AM
To: vpp-dev <vpp-dev@lists.fd.io>
Subject: [vpp-dev] Committer / Maintainer model.
Guys,
The discussion we had on the Tuesday meeting about the maintainers file got me
thinking.
I think there are two problems with the current model.
- It puts a high burden on the committers, since at least one among the
committer set has to know every piece of the code.
Aka. it doesn't scale very well.
- It doesn't allow the code authors aka maintainers of a given component any
control of changes to 'their' component.
Proposal:
1) Each component has a set of owners (or named list).
2) When a change is submitted. A gerrit hook processes the list of changed
files, and automatically adds the component owner lists or individuals to the
reviews list.
(e.g. Ole Troan (vnet/map), Neale Ranns (vnet/ip))
3) A committer will then see when maintainers have +1 for each affected
component. And then either submit or chase component owners for review.
A maintainer can then raise a "discuss" by a -1.
If there is support for this we need to:
- create maintainer file (and keep this up to date)
- write gerrit hook
Btw, Damjan pointed me to the Xen project's definition of maintainers vs
committers:
----
Maintainers
Maintainers own one or several components in the Xen tree. A maintainer reviews
and approves changes that affect their components. It is a maintainer's prime
responsibility to review, comment on, co-ordinate and accept patches from other
community member's and to maintain the design cohesion of their components.
Maintainers are listed in a MAINTAINERS file in the root of the source tree.
Committers
Committers are Maintainers that are allowed to commit changes into the source
code repository. The committer acts on the wishes of the maintainers and
applies changes that have been approved by the respective maintainer(s) to the
source tree. Due to their status in the community, committers can also act as
referees should disagreements amongst maintainers arise. Committers are listed
on the sub-project's team portal (e.g. Hypervisor team portal).
----
Views?
Best regards,
Ole
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
