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
