The point of all of this wasn't about Cumulus or not. We've had multiple people state that the process takes too long multiple times recently. The point was that patches are piling up across the *community* at a rate greater than they are even being looked at. I see no way that we can reach unanimity for every patch. Nor do I see any advantage to 2 month long arguments about issues. I would like a process where we can resolve issues at a faster rate.
donald On Wed, May 18, 2016 at 8:54 AM, Paul Jakma <[email protected]> wrote: > On Tue, 17 May 2016, Donald Sharp wrote: > > Proposal for going forward: >> >> 1. Patch Submitted >> 2. If Acked goes in immediately to a development branch, by current >> maintainer. >> 3. If no-one says anything after 2 weeks, immediately get’s put into a >> development branch by current maintainer. >> 4. If Nacked, dissenter and submitter must publicly work the issue out, >> and going back to step 1 after working issue out. >> 5. If after 2 weeks, from Submittal, dissenter and submitter cannot >> figure the problem out either Dissenter or Submitter can ask for agenda >> item to be added to next monthly meeting. If disagreement is large >> enough >> a special meeting can be asked for as well. >> > > > Format for Resolution during Meeting: >> >> >> >> 1. Discussion on alias( See #4 ) must be sufficient for Meeting to >> resolve the issue. Meeting attendees are within their rights to say we >> can’t make a decision from fact’s presented at the meeting. >> 2. Simple Majority of those attending meeting is required for decision. >> If you can’t be bothered to attend then the decision wasn’t important to >> you. >> 3. Scheduling of a special meeting details must be worked out publicly >> on quagga-dev alias. >> > > In general, I don't think it is correct to have a globally distributed > open-source project rely on a "must be present at this specific point of > time" protocol for resolving things. On "If you can't be bothered to attend > then the decision wasn't important to you", I will accept this if you're > happy to get up in the middle of the night for calls. > > E.g., there definitely are engineers in, say, India working on Quagga. If > not working on Quagga.net, I'd like them to be able to at least in time. > > The issue is to have time-bounded and clear decisions. There is 0 reason > why the final vote can not be done with structured voting protocols via a > mailing list, with a wider window of time that is easier for a wider group > of people to deal with and with a clear deadline. > > Moving to what is driving this, the Cumulus backlog, I am somewhat uneasy > at moving to a process driven just by that. I am uneasy at moving to a > process that makes it easier for one set of contributors to club together > and over-ride other contributors. > > In particular, I have some concerns that a factor driving this is that > Cumulus is somewhat resistant to review, and in particular quite resistant > to dropping patches. > > There are of course many issues that got us here. Quagga had a resource > problem for a while, maintainers were getting burned out (I certainly was > very burned out around '08). Those issues were of course significant in > Cumulus building up that initial backlog. No doubt that in part led Cumulus > to disengage to some degree. However, attempts to re-engage and deal with > the back-log have had problems. > > Things have improved significantly with your arrival, and I think we've > made improvements on speed of getting stuff in, and on process. Least we > were, but it seems to have stalled a bit again. > > And I am concerned about some things. The take-3 branch has patches that I > reviewed in *2014*. I started with NetDEF and started going through the > Cumulus tree then, along with David. We got some stuff in (about half of > the patches looked at) and some stuff I sent queries or comments or > pushback on to Cumulus. I never heard anything back. The same patches keep > coming back too. Even in recent times, I have queried patches, not heard > anything back and then they just re-appear in the next submission. > > On take-3, I spent a non-trivial amount of time going through that. And > gave comments. Most can go in. Some have nits (e.g. random other unrelated > changes), some nits I just fixed there and then. Other patches are odd - > the commit message doesn't explain why it exists (the one I'm thinking of > is one of the ones I similarly queried in 2014). Another set of patches are > blocked by changes needed to one patch, change I think we agreed on. > > However, rounds 7 and (now too) rounds 8 seem to be held hostage to > resolving take-3 - it sort of feels like. > > Further, if we go with this process you propose, what then? So my comments > can end being ignored, and take-3 just goes into Quagga. And then, you have > also stated Cumulus is producing further patches at a high rate - that we > havn't even seen. I won't really be able to meaniningfully comment on those > either? > > So we can just go produce large sets of patches behind closed doors, and > if we can fling them at the list fast enough, and marshall support from > (n-1)/2+1 others, then we can just shovel stuff in? > > The issue I have is that I'm far from sure that's how I want to work on > Quagga. > > regards, > -- > Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A > Fortune: > To communicate is the beginning of understanding. > -- AT&T
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
