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

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

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

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

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

[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

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

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

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

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

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

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) > wrote: Hello, I had a look on current

[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