Forgive me for not having read through in detail, I just wanted to mention two models I found while googling:
1. The Linux model has a large number of maintainers. It looks like they break up the kernel in various ways. So each driver will have a maintainer. But also, different layers and subsystems each have a maintainer. So it becomes a matter of deciding how to break up VPP along different dimensions. I believe maintainers == committers in that model. 2. I saw an Apache Mesos project that has both committers and maintainers. In their model, maintainers are a subset of committers that have a great deal of knowledge in their subject area. So they are only called upon when extra knowledge is required. OK, time for me to stick my nose elsewhere; I just thought I'd report what I have read. Burt On Wed, Dec 21, 2016 at 10:57 AM, Kinsella, Ray <ray.kinse...@intel.com> wrote: > Hi Joel, > > Thanks for asking - I think I would be fine with that model. I think it > would clarify who owns what and who is to go to for what. > > A list of committers and a second list of maintainers (reviewers), feels > like bureaucracy. > > * I can see people on the maintainer list getting frustrated over time > without an obvious path to become a committer. > * If a maintainer requires a committer's final approval in any case, it > may not solve the scaling problem we have at the moment. > * In practice, I am not sure what sure what a committers approval will add > on top of the maintainers approval. > > Thanks, > > Ray K > > > > On 21/12/2016 15:47, Joel Halpern wrote: > >> Ray, I think you are suggesting a more basic change. That instead of >> having committers for a project, we have committers on a per-feature basis >> (where a single committer may be listed for several features in a >> project.) Is that the model you are looking for? >> >> Yours, >> Joel >> >> -----Original Message----- >> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] >> On Behalf Of Kinsella, Ray >> Sent: Wednesday, December 21, 2016 10:44 AM >> To: Damjan Marion <dmarion.li...@gmail.com> >> Cc: vpp-dev <vpp-dev@lists.fd.io> >> Subject: Re: [vpp-dev] Committer / Maintainer model. >> >> >> If the bottleneck here is committers are not familiar enough with a >> feature to review or approve - and these are stacking up, should they >> really have have commit rights for that feature? >> >> If we are asking maintainers to be domain experts for a feature, to own >> it, why have the extra bureaucracy of the additional committer approval. >> Will 'committer' approval on top of 'maintainer' approval ultimately >> anything but overhead? >> >> Ray K >> >> >> On 21/12/2016 15:36, Damjan Marion wrote: >> >>> >>> On 21 Dec 2016, at 15:58, Kinsella, Ray <ray.kinse...@intel.com> wrote: >>>> >>>> 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. >>>> >>> >>> My view here is completelly different, maintainer should have authority >>> of his feature. >>> I.e. if somebody owns vagrant stuff, he should be asked to +1 on any >>> non-trivial change. >>> If maintainer is busy with something else and not taking much care >>> about it anymore, then we either need to find another one or we should >>> remove it completelly from the repo. >>> >>> What we have today is broken, there is many unmaintained stuff in the >>> repo which went out of sync with time and if somebody submits patch to >>> the gerrit, I (and I guess other committers also) don't have a clue what >>> to do with it, as i really never started vagrant in my life. >>> >>> Same story with vppctl, rpm packaging, different plugins... >>> >>> >>> >>> >>> _______________________________________________ >> 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 >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
