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 <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] *On > Behalf Of *Florin Coras > *Sent:* Wednesday, December 21, 2016 15:44 > *To:* Damjan Marion <dmarion.li...@gmail.com> > *Cc:* vpp-dev <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 <dmarion.li...@gmail.com> > wrote: > > > > > On 21 Dec 2016, at 18:49, Kinsella, Ray <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 > 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
