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

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

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 par

Re: [vpp-dev] 17.01 stable branch to be created tomorrow - Dec 21st

stable/1701 branch is created and tagged with RC1 tag. I will soon put 17.04-rc0 tag on the master and then master is back in business…. > On 20 Dec 2016, at 15:25, Damjan Marion (damarion) wrote: > > > Dear VPP developers, > > Tomorrow, we are planning to create stable 17.01 branch and rele

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

> 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

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

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

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

> 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

[vpp-dev] Happy Solstice and holidays!

All - Given the holiday today, I’ll wax a bit on the accomplishments of fd.io over the last 12 months. February 11, 2016, fd.io launched. It's purpose was to build the software dataplane for the next Internet architectural constructs. Something so high perform

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

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 subsyste

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

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

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

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

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

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

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

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

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 bureaucrac

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

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

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

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

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

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

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

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

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

Re: [vpp-dev] QQs on VPP clone.sh

As promised, the rsync changes are here. https://gerrit.fd.io/r/4449 I also came across another issues with Vagrant ubuntu setup, which I resolved here. https://gerrit.fd.io/r/4450 Ray K On 20/12/2016 22:34, Ed Warnicke wrote: I think that has the potential to be a brilliant solution. Co

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

> 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

Re: [vpp-dev] [csit-dev] CSIT for 17.01 release

Jan, Makes sense to me, thx for taking it on. We will cover it on csit call today, and update status here for folks.. -Maciek On 20 Dec 2016, at 21:33, Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) mailto:jgel...@cisco.com>> wrote: Hello, I had a look on current status of CSIT relat

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

> 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

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

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 gen

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