On Wed, 18 May 2016, Lou Berger wrote:
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.
We've barely tried getting the recent changes up to speed.
If you don't like the proposed text/process description, how do you
propose to fix the process going forward?
For the Cumulus backlog. We knuckle down, and churn through triaging
their queue into the "obviously good to go in" stuff, fix the nits in
the rest, etc.
We work hard at that. We get good at doing integration rounds. We make
it faster. We figure out how to optimise that. We can deal with the
backlog. I'm also happy to help with the rebasing work, which I know is
a laborious, difficult and thankless task.
However, I think it also requires Cumulus to get better at tracking and
dealing with comments on contributions. Just as there were issues on the
Quagga side (for understandable reasons, no doubt), and we have to fix
them; so there seem to be some contributing issues on the Cumulus side
(again, no doubt for reasonable and/or perfectly understandable
reasons), and those need to be fixed too to make this work. Whether
that's just logistics, or more, I don't know.
It's perfectly doable though I think, even if it's going to mean extra
hard work for a while to deal with the backlog.
Ignoring the backlog, if Cumulus are producing stuff faster than the
upsteam "queue-review-address" cycle via Donald could keep up with, then
perhaps Cumulus need to look at distributing the upstreaming
responsibility a bit more so that the individual Cumulus developers are
more active on that (and yes, dealing with the backlog may be critical
to make that work).
Cause otherwise, even without a backlog, what's being asked for is a
process that allows larger teams to develop behind closed doors and be
able ultimately to ignore outside review. At which point, why even
bother with the community project?
But again, I think we /can/ get Cumulus' backlog worked through, and get
the review->{accept,nits,reject} cycle working. However, we need to give
it a good go. It was getting up to speed late last year. I got a whole
bunch of stuff in. Donald then took the rounds-keeper/whatever hat
on, got a bunch of stuff in, was building up speed, and then it stalled
a bit again.
And it's stalled on take-3 for reasons due to a backlog from before
where we tried to fix the process, due to reasons that are /not/
entirely due to shortcomings on the Quagga side. I can understand there
are frustrations in dealing with that backlog, but I don't see that
setting the review process aside potentially is the answer.
The answer is to tackle that damn backlog, not get frustrated, keep
going, and get it down.
On contentious decisions, that's somewhat a separate issue I think. I do
feel it would be /much/ better to have strong motivating factors to
guide consensus building and constructive-disagreement. From hard won
experience, people can feel /very/ strongly about stuff. When there's
strong disagreement, the least worst option tends to be not have it in
rather than shove it in over the strong feelings of a minority. It may
be easier to live with some carrying a patch in their local branch, for
feelings to cool off, for time to bring perspective on whatever issue it
was, and for people to come back later and make a case again (if the
issue still exists).
regards,
--
Paul Jakma p...@jakma.org @pjakma Key ID: 64A2FF6A
Fortune:
Our business in life is not to succeed but to continue to fail in high spirits.
-- Robert Louis Stevenson
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
