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
