My 2c is that my experience of this model is that maintainers typically get
frustrated and disillusioned over time and become inactive, as they feel they
are minions, doing the tough and often invisble review work but with no real
authority over a feature. You end up with maintainer churn etc.
That is why I push for a strong correlation between maintainers and committers.
Committers should be a maintainer of something and the number of maintainers
who are not committers should be small. A maintainer with no commit rights,
should be a committer in waiting with a clear path to graduating to be a
committer.
I see that. Interesting to see how it develops. Not suggesting we should cast
this in stone. .
Understand why we want to make a change, want to ensure we move to a
sustainable model.
I imagined the opposite. That a maintainer had super-powers for his feature,
but perhaps wasn't so interested in the rest of the system. Then the role of
the committer is more one of architectural oversight and someone who ensures
that the right hoops were jumped.
In that case the committer, needs to review everything that a maintainer
has already approved, to ensure it is 'architecturally agreeable' and
'boxes have been ticked'. Kinda sounds like we are doubling the work?
I kind of think of a maintainer as a committer for a particular
feature/area/plugin.
Well if they are a 'committer' then dispense with the extra bureaucracy
and give them commit rights?
Try and then adjust as we go along?
Cheers,
Ole
Ray K
On 21/12/2016 12:18, Ole Troan wrote:
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
