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
