Ray, > I suspect the Maintainers versus Committers description was included for my > benefit :-)
Most definitely not! :-) Agreeing on the right words to use for something is half the battle. > 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. . 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. I kind of think of a maintainer as a committer for a particular feature/area/plugin. 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
