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
lto: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 pl
: [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
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 par
> 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
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
> 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 great
>> 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
t 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.
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
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 co
[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 mode
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 bureaucrac
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
> 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
> aut
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 disillu
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
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
R
> 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
> 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 ge
-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
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 scal
22 matches
Mail list logo
