Paul,
I respect that there's a lot of past history and hard work that has gotten
quagga to where it is now. Perhaps the added patch load and feature
discussions should be viewed as indications of success.
The thing that prompted me to raise this topic at the last meeting really
is the pace at which releases , patches, new features, etc are occurring.
Simply put, and I think supported by others on the call, it seems to me
that the current process isn't working.
On the call, we came up with basically what I think Donald has outlined. I
think he fairly accurately captured comme ts made by all the participants,
and doesn't just represent his opinion.
If you don't like the proposed text/process description, how do you propose
to fix the process going forward?
Thanks,
Lou
On May 18, 2016 8:57:32 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
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
