Paul,
see below
On 5/19/2016 6:45 AM, Paul Jakma wrote:
> 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.
One of the issues I have is that there seems to be no documentation on
what the current process is, or how it should work. From the outside,
we (folks on the mailing list) just aren't seeing progress. I accept
things may be happening off-list, but I think it needs to happen on-list
to (a) demonstrate progress and (b) scale the review work to those
willing to contribute.
>
>> 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.
So for the rest of us, it would be good to have the release process
documented so we know how to contribute to it. If you don't like what
the process as described in the other mail, can you send out your version?
> 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).
I think if we keep patch comments/discussion on list from the start,
this will greatly help resolving the discussions completely on list and
in, hopefully, a timely fashion -- which is what I think all prefer.
It'll also show when a patch submitter is no longer interested in
getting issue with a blocked patch resolve.
Lou
> regards,
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
