Re: [vpp-dev] Committer / Maintainer model.

[Dave Barach (dbarach)]

Item added to https://wiki.fd.io/view/VPP/Meeting#Agenda

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Ed Warnicke
Sent: Monday, February 6, 2017 7:37 PM
To: Luke, Chris 
Cc: vpp-dev ; Damjan Marion 
Subject: Re: [vpp-dev] Committer / Maintainer model.

In the frenzy around the 17.01 release, this seems to have died down a bit.  
Seems worth revitalizing the discussion somewhat, as it appears to have
been productive.

I tend to be something of an incrementalist, and strongly opposed to layering 
too much bureaucracy on things, but sometimes finding a way to restructure 
input can be helpful without bringing extra weight... so lets explore it a bit 
:)

Towards that end, I would suggest:

1)  Let's talk about this in the vpp call tomorrow morning (Dave, if I could 
impose, would you add this to the agenda)
2)  Let's look into getting a gerrit to discuss around a MAINTAINER file.  I 
personally tend to find it is easier to talk around a gerrit in circumstances 
like this
3)  Let's look into what it would take to get gerrit to auto assign reviewers 
based on that file
4)  Discuss how folks feel about the the vpp committers adopting among 
themselves a policy of waiting for and respecting +1/-1 from maintainers 
impacted by a patch.  Clearly, committers have to retain the right to exercise 
judgment, but maybe something like adding a comment to the gerrit to provide 
clarity when they do not wait for a review from an impacted maintainer would 
also be a good social expectation to develop.

Basically, let's explore the mechanics that would make it possible to explore 
this space, and talk about what would be good social conventions to try out.

Thoughts?

Ed

On Wed, Dec 21, 2016 at 4:44 PM, Luke, Chris 
mailto:chris_l...@comcast.com>> wrote:
If the issue is that of plugins, then I would concur, though tangentially there 
still seems to be some work to harmonize how projects produce their artifacts. 
Dividing things into projects has the neat property that those whose 
maintainers become negligent cause the project to wither on the vine and 
naturally die off.

Not having witnessed the discussion on the VPP call that started this though 
(I’m out this week[1]) what is it that is driving this discussion?

I really want to avoid protracted hierarchy, which I doubt will solve the 
problem and worse may give the appearance of solving it. I dislike the 
accompanying bureaucracy that, for example, some OpenStack projects exhibit. It 
is my observation that in such projects the discussion becomes more the 
politics of a change than the merit of it. I do not have the time for such 
games.

Cheers,
Chris.

[1] Which today involves a story about my arm being up-to-the-elbow in my 
furnace… but a tale of misadventure for another time perhaps. :)

From: vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io> 
[mailto:vpp-dev-boun...@lists.fd.io<mailto:vpp-dev-boun...@lists.fd.io>] On 
Behalf Of Florin Coras
Sent: Wednesday, December 21, 2016 15:44
To: Damjan Marion mailto:dmarion.li...@gmail.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Committer / Maintainer model.

Wouldn’t it be better to have separate projects for each plugin (or maybe 
groups of them) and thereby have maintainers automatically become committers 
within their respective projects? As far as I can see this diminishes load on 
VPP committers and gives the required ‘power' to the interested parties.

Just my 0.02$

Florin

On Dec 21, 2016, at 10:25 AM, Damjan Marion 
mailto:dmarion.li...@gmail.com>> wrote:


On 21 Dec 2016, at 18:49, Kinsella, Ray 
mailto:ray.kinse...@intel.com>> wrote:


If somebody submits plugin change + 3 lines of new
code in critical ip4 path, I will greatly benefit from +1 received from
plugin maintainer and i will focus on this 3 lines.
If I don’t have +1 from plugin maintainer, i will just left whole diff
in the gerrit, simply because i don't have a clue about that plugin.

But really, the committer will have nothing to add about the plugin in this 
case.

A more efficient process would be to let an IPv4 committer review and commit 
the IPv4 change, with the Plugin committer separately doing likewise.

Many open source project require that patches be made separately for component.

Yes, and hire one guy to bitch with people who are not following that rule...
___
vpp-dev mailing list
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
https://lists.fd.io/mailman/listinfo/vpp-dev


___
vpp-dev mailing list
vpp-dev@lists.fd.io<mailto: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

Re: [vpp-dev] Committer / Maintainer model.

[Ed Warnicke]

In the frenzy around the 17.01 release, this seems to have died down a
bit.  Seems worth revitalizing the discussion somewhat, as it appears to
have
been productive.

I tend to be something of an incrementalist, and strongly opposed to
layering too much bureaucracy on things, but sometimes finding a way to
restructure input can be helpful without bringing extra weight... so lets
explore it a bit :)

Towards that end, I would suggest:

1)  Let's talk about this in the vpp call tomorrow morning (Dave, if I
could impose, would you add this to the agenda)
2)  Let's look into getting a gerrit to discuss around a MAINTAINER file.
I personally tend to find it is easier to talk around a gerrit in
circumstances like this
3)  Let's look into what it would take to get gerrit to auto assign
reviewers based on that file
4)  Discuss how folks feel about the the vpp committers adopting among
themselves a policy of waiting for and respecting +1/-1 from maintainers
impacted by a patch.  Clearly, committers have to retain the right to
exercise judgment, but maybe something like adding a comment to the gerrit
to provide clarity when they do not wait for a review from an impacted
maintainer would also be a good social expectation to develop.

Basically, let's explore the mechanics that would make it possible to
explore this space, and talk about what would be good social conventions to
try out.

Thoughts?

Ed

On Wed, Dec 21, 2016 at 4:44 PM, Luke, Chris  wrote:

> If the issue is that of plugins, then I would concur, though tangentially
> there still seems to be some work to harmonize how projects produce their
> artifacts. Dividing things into projects has the neat property that those
> whose maintainers become negligent cause the project to wither on the vine
> and naturally die off.
>
>
>
> Not having witnessed the discussion on the VPP call that started this
> though (I’m out this week[1]) what is it that is driving this discussion?
>
>
>
> I really want to avoid protracted hierarchy, which I doubt will solve the
> problem and worse may give the appearance of solving it. I dislike the
> accompanying bureaucracy that, for example, some OpenStack projects
> exhibit. It is my observation that in such projects the discussion becomes
> more the politics of a change than the merit of it. I do not have the time
> for such games.
>
>
>
> Cheers,
>
> Chris.
>
>
>
> [1] Which today involves a story about my arm being up-to-the-elbow in my
> furnace… but a tale of misadventure for another time perhaps. :)
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Florin Coras
> *Sent:* Wednesday, December 21, 2016 15:44
> *To:* Damjan Marion 
> *Cc:* vpp-dev 
> *Subject:* Re: [vpp-dev] Committer / Maintainer model.
>
>
>
> Wouldn’t it be better to have separate projects for each plugin (or maybe
> groups of them) and thereby have maintainers automatically become
> committers within their respective projects? As far as I can see this
> diminishes load on VPP committers and gives the required ‘power' to the
> interested parties.
>
>
>
> Just my 0.02$
>
>
>
> Florin
>
>
>
> On Dec 21, 2016, at 10:25 AM, Damjan Marion 
> wrote:
>
>
>
>
> On 21 Dec 2016, at 18:49, Kinsella, Ray  wrote:
>
>
>
> If somebody submits plugin change + 3 lines of new
> code in critical ip4 path, I will greatly benefit from +1 received from
> plugin maintainer and i will focus on this 3 lines.
> If I don’t have +1 from plugin maintainer, i will just left whole diff
> in the gerrit, simply because i don't have a clue about that plugin.
>
>
> But really, the committer will have nothing to add about the plugin in
> this case.
>
> A more efficient process would be to let an IPv4 committer review and
> commit the IPv4 change, with the Plugin committer separately doing likewise.
>
> Many open source project require that patches be made separately for
> component.
>
>
> Yes, and hire one guy to bitch with people who are not following that
> rule...
> ___
> 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

Re: [vpp-dev] Committer / Maintainer model.

[Luke, Chris]

If the issue is that of plugins, then I would concur, though tangentially there 
still seems to be some work to harmonize how projects produce their artifacts. 
Dividing things into projects has the neat property that those whose 
maintainers become negligent cause the project to wither on the vine and 
naturally die off.

Not having witnessed the discussion on the VPP call that started this though 
(I’m out this week[1]) what is it that is driving this discussion?

I really want to avoid protracted hierarchy, which I doubt will solve the 
problem and worse may give the appearance of solving it. I dislike the 
accompanying bureaucracy that, for example, some OpenStack projects exhibit. It 
is my observation that in such projects the discussion becomes more the 
politics of a change than the merit of it. I do not have the time for such 
games.

Cheers,
Chris.

[1] Which today involves a story about my arm being up-to-the-elbow in my 
furnace… but a tale of misadventure for another time perhaps. :)

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Florin Coras
Sent: Wednesday, December 21, 2016 15:44
To: Damjan Marion 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Committer / Maintainer model.

Wouldn’t it be better to have separate projects for each plugin (or maybe 
groups of them) and thereby have maintainers automatically become committers 
within their respective projects? As far as I can see this diminishes load on 
VPP committers and gives the required ‘power' to the interested parties.

Just my 0.02$

Florin

On Dec 21, 2016, at 10:25 AM, Damjan Marion 
mailto:dmarion.li...@gmail.com>> wrote:


On 21 Dec 2016, at 18:49, Kinsella, Ray 
mailto:ray.kinse...@intel.com>> wrote:



If somebody submits plugin change + 3 lines of new
code in critical ip4 path, I will greatly benefit from +1 received from
plugin maintainer and i will focus on this 3 lines.
If I don’t have +1 from plugin maintainer, i will just left whole diff
in the gerrit, simply because i don't have a clue about that plugin.

But really, the committer will have nothing to add about the plugin in this 
case.

A more efficient process would be to let an IPv4 committer review and commit 
the IPv4 change, with the Plugin committer separately doing likewise.

Many open source project require that patches be made separately for component.

Yes, and hire one guy to bitch with people who are not following that rule...
___
vpp-dev mailing list
vpp-dev@lists.fd.io<mailto: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

Re: [vpp-dev] Committer / Maintainer model.

[Florin Coras]

Wouldn’t it be better to have separate projects for each plugin (or maybe 
groups of them) and thereby have maintainers automatically become committers 
within their respective projects? As far as I can see this diminishes load on 
VPP committers and gives the required ‘power' to the interested parties. 

Just my 0.02$

Florin

> On Dec 21, 2016, at 10:25 AM, Damjan Marion  wrote:
> 
>> 
>> On 21 Dec 2016, at 18:49, Kinsella, Ray  wrote:
>> 
>> 
>>> If somebody submits plugin change + 3 lines of new
>>> code in critical ip4 path, I will greatly benefit from +1 received from
>>> plugin maintainer and i will focus on this 3 lines.
>>> If I don’t have +1 from plugin maintainer, i will just left whole diff
>>> in the gerrit, simply because i don't have a clue about that plugin.
>> 
>> But really, the committer will have nothing to add about the plugin in this 
>> case.
>> 
>> A more efficient process would be to let an IPv4 committer review and commit 
>> the IPv4 change, with the Plugin committer separately doing likewise.
>> 
>> Many open source project require that patches be made separately for 
>> component.
> 
> Yes, and hire one guy to bitch with people who are not following that rule...
> ___
> 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

Re: [vpp-dev] Committer / Maintainer model.

[Damjan Marion]

> On 21 Dec 2016, at 18:49, Kinsella, Ray  wrote:
> 
> 
>> If somebody submits plugin change + 3 lines of new
>> code in critical ip4 path, I will greatly benefit from +1 received from
>> plugin maintainer and i will focus on this 3 lines.
>> If I don’t have +1 from plugin maintainer, i will just left whole diff
>> in the gerrit, simply because i don't have a clue about that plugin.
> 
> But really, the committer will have nothing to add about the plugin in this 
> case.
> 
> A more efficient process would be to let an IPv4 committer review and commit 
> the IPv4 change, with the Plugin committer separately doing likewise.
> 
> Many open source project require that patches be made separately for 
> component.

Yes, and hire one guy to bitch with people who are not following that rule...
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

If somebody submits plugin change + 3 lines of new
code in critical ip4 path, I will greatly benefit from +1 received from
plugin maintainer and i will focus on this 3 lines.
If I don’t have +1 from plugin maintainer, i will just left whole diff
in the gerrit, simply because i don't have a clue about that plugin.


But really, the committer will have nothing to add about the plugin in 
this case.


A more efficient process would be to let an IPv4 committer review and 
commit the IPv4 change, with the Plugin committer separately doing 
likewise.


Many open source project require that patches be made separately for 
component.


Ray K
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Damjan Marion]

> On 21 Dec 2016, at 16:57, Kinsella, Ray  wrote:
> 
> * If a maintainer requires a committer's final  approval in any case, it may 
> not solve the scaling problem we have at the moment.

I fully disagree. If somebody submits plugin change + 3 lines of new code in 
critical ip4 path, I will greatly benefit from +1 received from plugin 
maintainer and i will focus on this 3 lines.
If I don’t have +1 from plugin maintainer, i will just left whole diff in the 
gerrit, simply because i don't have a clue about that plugin.

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Burt Silverman]

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 
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 
>> Cc: vpp-dev 
>> 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  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

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

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 
Cc: vpp-dev 
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  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

Re: [vpp-dev] Committer / Maintainer model.

[Joel Halpern]

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 
Cc: vpp-dev 
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  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

Re: [vpp-dev] Committer / Maintainer model.

[Ole Troan (otroan)]

Ray,

> Well if they are a 'committer' then dispense with the extra bureaucracy and 
> give them commit rights?

It's a matter of granularity really. 
I could certainly imagine myself only having control of vnet/map and  not want 
to have responsibility or authority over anything else. 

When it comes down to it this is all merits based anyway. 

I hoped more less centralized bureaucracy and more distributed power, but I am 
sure that's what the great Russian leaders over the past centuries tried to 
achieve too. :-)

Best regards,
Ole
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Joel Halpern]

There is an element in your note of there being a single person (or pair) with 
practical veto power over a component.
I thought the switch in terminology from owner to maintainer was in part to 
avoid that implication.

As I had read it, a maintainer was someone who was promising to put in energy 
to keep a component current.  That does not make him the owner.  If he is busy, 
or just personally clashes with another contributor (we are human), someone 
else ought to be able to review a commit.  

I appreciate the need to distribute work.  No one can or should have to know 
everything.  (Although some folks seem to be able to come close.)  But equally, 
an fd.io project is not a collection of fiefdoms.  So I would hope that we 
would be careful about how we describe the process to avoid encouraging that.

Yours,
Joel

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Damjan Marion
Sent: Wednesday, December 21, 2016 10:37 AM
To: Kinsella, Ray 
Cc: vpp-dev 
Subject: Re: [vpp-dev] Committer / Maintainer model.


> On 21 Dec 2016, at 15:58, Kinsella, Ray  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

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

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  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

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

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

Re: [vpp-dev] Committer / Maintainer model.

[Damjan Marion]

> On 21 Dec 2016, at 15:58, Kinsella, Ray  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

Re: [vpp-dev] Committer / Maintainer model.

[Ole Troan (otroan)]

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

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

Thanks Ole,

I suspect the Maintainers versus Committers description was included for 
my benefit :-)


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.


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

Re: [vpp-dev] Committer / Maintainer model.

[Kinsella, Ray]

The the addition of a Maintainers file would be a positive step. Can I 
also recommend that we include and distribute get_maintainer.pl. A 
script which automates the process of identifying the correct maintainer 
for a patch.


See: http://lxr.free-electrons.com/source/scripts/get_maintainer.pl

Ray K

On 21/12/2016 14:31, Damjan Marion wrote:



On 21 Dec 2016, at 14:35, Ole Troan  wrote:


That makes sense to me. We have a few problems to address:

1. Patches not being reviewed in a timely fashion
2. Committers spending too much time reviewing patches
3. Committers reviewing patches outside their area of expertise
4. Inability to filter code review request emails from general chit-chat, 
contributing to (1).

How about this?

O Based on the set of files / directories involved in a patch, gerrit 
automatically adds reviewers
O Email patch review requests w/ subject lines of the form [CODE-REVIEW] or 
some such
O Send email "to" the area owner(s), "cc" committers [who should know when 
folks are unavailable, etc.]
O Area owners score patches.
  O If they're also committers, feel free to +2.
  O Otherwise, email committers when satisfied to ensure timely merges

We know that gerrit can automatically add reviewers (see also "fd.io JJB").

This scheme depends on identifying folks that we trust to enforce a certain level of 
"truth, justice, and the right way," but it should help a lot in terms of our 
current committer scaling problem.


Wouldn't this be a self-selecting bunch, assuming it is the people who authored 
the code for the area in the first place?

Thanks for fleshing this out!

I think the added emails would help a lot in identifying who's responsible for 
what action. Currently we're suffering a bit from the bystander effect.

I'd be happy to have a first go at a maintainers file. I suggest we inherit the 
linux kernel format?

https://www.kernel.org/doc/linux/MAINTAINERS


I really support idea of putting MAINTAINERS file and using this standard 
format,
unless somebody can point us to law or other legal act which denies use of word 
“maintainer” in the fd.io.




___
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

Re: [vpp-dev] Committer / Maintainer model.

[Damjan Marion]

> On 21 Dec 2016, at 14:35, Ole Troan  wrote:
> 
>> That makes sense to me. We have a few problems to address:
>> 
>> 1. Patches not being reviewed in a timely fashion
>> 2. Committers spending too much time reviewing patches 
>> 3. Committers reviewing patches outside their area of expertise
>> 4. Inability to filter code review request emails from general chit-chat, 
>> contributing to (1).
>> 
>> How about this?
>> 
>> O Based on the set of files / directories involved in a patch, gerrit 
>> automatically adds reviewers
>> O Email patch review requests w/ subject lines of the form [CODE-REVIEW] or 
>> some such
>> O Send email "to" the area owner(s), "cc" committers [who should know when 
>> folks are unavailable, etc.]
>> O Area owners score patches. 
>>   O If they're also committers, feel free to +2. 
>>   O Otherwise, email committers when satisfied to ensure timely merges
>> 
>> We know that gerrit can automatically add reviewers (see also "fd.io JJB").
>> 
>> This scheme depends on identifying folks that we trust to enforce a certain 
>> level of "truth, justice, and the right way," but it should help a lot in 
>> terms of our current committer scaling problem.
> 
> Wouldn't this be a self-selecting bunch, assuming it is the people who 
> authored the code for the area in the first place?
> 
> Thanks for fleshing this out!
> 
> I think the added emails would help a lot in identifying who's responsible 
> for what action. Currently we're suffering a bit from the bystander effect.
> 
> I'd be happy to have a first go at a maintainers file. I suggest we inherit 
> the linux kernel format?
> 
> https://www.kernel.org/doc/linux/MAINTAINERS

I really support idea of putting MAINTAINERS file and using this standard 
format,
unless somebody can point us to law or other legal act which denies use of word 
“maintainer” in the fd.io.




___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Ole Troan]

> That makes sense to me. We have a few problems to address:
> 
> 1. Patches not being reviewed in a timely fashion
> 2. Committers spending too much time reviewing patches 
> 3. Committers reviewing patches outside their area of expertise
> 4. Inability to filter code review request emails from general chit-chat, 
> contributing to (1).
> 
> How about this?
> 
> O Based on the set of files / directories involved in a patch, gerrit 
> automatically adds reviewers
> O Email patch review requests w/ subject lines of the form [CODE-REVIEW] or 
> some such
> O Send email "to" the area owner(s), "cc" committers [who should know when 
> folks are unavailable, etc.]
> O Area owners score patches. 
>O If they're also committers, feel free to +2. 
>O Otherwise, email committers when satisfied to ensure timely merges
> 
> We know that gerrit can automatically add reviewers (see also "fd.io JJB").
> 
> This scheme depends on identifying folks that we trust to enforce a certain 
> level of "truth, justice, and the right way," but it should help a lot in 
> terms of our current committer scaling problem.

Wouldn't this be a self-selecting bunch, assuming it is the people who authored 
the code for the area in the first place?

Thanks for fleshing this out!

I think the added emails would help a lot in identifying who's responsible for 
what action. Currently we're suffering a bit from the bystander effect.

I'd be happy to have a first go at a maintainers file. I suggest we inherit the 
linux kernel format?

https://www.kernel.org/doc/linux/MAINTAINERS

Best regards,
Ole
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Dave Barach (dbarach)]

Dear Ole,

That makes sense to me. We have a few problems to address:

1. Patches not being reviewed in a timely fashion
2. Committers spending too much time reviewing patches 
3. Committers reviewing patches outside their area of expertise
4. Inability to filter code review request emails from general chit-chat, 
contributing to (1).

How about this?

O Based on the set of files / directories involved in a patch, gerrit 
automatically adds reviewers
O Email patch review requests w/ subject lines of the form [CODE-REVIEW] or 
some such
O Send email "to" the area owner(s), "cc" committers [who should know when 
folks are unavailable, etc.]
O Area owners score patches. 
O If they're also committers, feel free to +2. 
O Otherwise, email committers when satisfied to ensure timely merges

We know that gerrit can automatically add reviewers (see also "fd.io JJB").

This scheme depends on identifying folks that we trust to enforce a certain 
level of "truth, justice, and the right way," but it should help a lot in terms 
of our current committer scaling problem.

Thoughts?  

Thanks... Dave

-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Ole Troan
Sent: Wednesday, December 21, 2016 7:18 AM
To: vpp-dev 
Subject: [vpp-dev] Committer / Maintainer model.

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

[vpp-dev] Committer / Maintainer model.

[Ole Troan]

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