On Fri, 24 Jun 2016, Lou Berger wrote:
I personally don't recall a discussion on this on list, but perhaps
missed it.
Well, we started this last year with Vincent leading by example and just
getting stuck in to stuff in patchwork, reviewing it and summarising to
list:
https://lists.quagga.net/pipermail/quagga-dev/2015-June/012751.html
I brought up workflows and using git branches to track:
https://lists.quagga.net/pipermail/quagga-dev/2015-June/012859.html
I also mentioned having some kind of technical panel / committee
whatever:
https://lists.quagga.net/pipermail/quagga-dev/2015-June/012804.html
[I have actually had that kind of discussion with various people, inc.
Greg and Martin over the years, on NPOs (UK has very low overhead
options here), on having technical committees with constitution docs,
etc. Greg has mentioned SPI in the past. Often the feedback has been
(inc. from Martin on the "Quagga Architecture Review Committee" proposal
I had discussed with him over a year ago) that these things seem too
formal and high-overhead for a free software project. I've actually been
*persuaded* by that, and now mostly think the important thing is to just
get on with the technical stuff].
After Vincent got the ball rolling:
https://lists.quagga.net/pipermail/quagga-dev/2015-July/012966.html
https://lists.quagga.net/pipermail/quagga-dev/2015-August/013032.html
https://lists.quagga.net/pipermail/quagga-dev/2015-September/013172.html
https://lists.quagga.net/pipermail/quagga-dev/2015-October/013352.html
Note that as of round-3, the incoming since that process was started
(and a bit more) was dealt with. It was keeping up with what was coming
in.
Donald started with rebasing Cumulus patches, take-1:
https://lists.quagga.net/pipermail/quagga-dev/2015-November/013591.html
Take-2:
https://lists.quagga.net/pipermail/quagga-dev/2015-November/013637.html
Take-3:
https://lists.quagga.net/pipermail/quagga-dev/2015-November/013683.html
I pointing out I had long-standing comments on some. Also, some new ones
generate a discussion, but are re-staged.
Donald starts r5:
https://lists.quagga.net/pipermail/quagga-dev/2015-November/013952.html
Also, more versions of take-3:
https://lists.quagga.net/pipermail/quagga-dev/2015-December/014154.htmlhttps://lists.quagga.net/pipermail/quagga-dev/2015-December/014154.html
https://lists.quagga.net/pipermail/quagga-dev/2015-December/014221.html
I'm not blaming anyone per se - stuff goes missing sometimes, and things
are harder to track when there are large backlogs - but both still have
various patches with comments. The comments were either mentioned recent
to above, or there was even a discussion on the list recent to that
(e.g. lifting the cluster-ID check in the BGP decision process).
We had round 6, which mostly went on behind the scenes.
We had a discussion on tools in Jan, e.g. on Gerrit:
https://lists.quagga.net/pipermail/quagga-dev/2016-January/014620.html
It's worth noting that Gerrit's workflow is very much based around
rebasing - for those complaining about rebasing.
A summary of the governance status and contribution proces was sent to
the list in Feb:
https://lists.quagga.net/pipermail/quagga-dev/2016-February/014883.html
Updating HACKING was lagging, but there were other changes to HACKING
still being discussed I think. However, the whole point is that this
process should be somewhat self-documenting to contributors by way of
summary emails and git branches. E.g.:
http://git.savannah.gnu.org/cgit/quagga.git/refs/
or 'git fetch <quagga git remote name>' and you *see* the refs for the
rounds being fetched, and you can easily examine them with 'gitk --all'.
Now, could be that still isn't clear enough, in which case, we need some
other tool. So discuss that. I lean toward bugzilla as the canonical ID
and place for contributors and submissions' status, with patchwork as a
backend-tool to help integrators with tracking list activity.
I also don't see the process documented anywhere. Also, it's unclear
how patches Ack'ed on list would end up anywhere but accepted. --
Keep in mind, my perspective is as user and contributor, not
maintainer.
This "Ack'ed" stuff - where did that come from?
See above, I'd been working on a "queue it all" -> "summarise" -> sift
out anything with objections basis for all the rounds I've done.
It comes down to where I should do my development, test and
submissions. Right now there is no changes between releases except at
the last minute (or couple of weeks). This means:
- no testing on ack'ed patches
NetDEF's CI system?
- no easy way for a user to see if an issue is addressed by the dev branch
- submitted patches are often out of date (and need rebasing) and
occasionally are duplicative
Rebasing is a fact of life. Get used to it. Be great not to have to do
so, but only way to get that is to just go work on your tree and ignore
everything else.
Speeding up integration cycles could reduce how often this happens.
However there are some fundamental tensions here, and even with really
fast, rebasing is still going to be required of people.
There are no magic ponies, sorry.
I have no idea. I only got involved beyond the contributor level once
things broke down.
We were keeping up (notwithstanding old backlog) with r3 and r4. Donald
had to get up to speed on r5 I guess. r6 was unusual - and that process
will never be repeated ;). For r7 I was working with Donald to sort
through his take-3 (the one with multiple patches that seem resistant to
review comments) - that seemed to be going productively for a while.
Then Donald seemed to decide to take a different tack; rather than get
through the review comments, he wanted to just have take-3 go in
whole-sale. When I didn't agree to that, he instead agitated for this
"Development is broken! Everything must change! Here's how nothing
really changes, except it gives a path to get around paul's comments".
He then sat on round-7, not integrating anything but a few bug fixes -
which (consciously or not) seems like a way to engineer a crisis.
So, where did things break down?
How was that a useful, progressive approach to dealing with the backlog?
What about any of the 3 discussed documents leads you to conclude they
are clean-sheet documents? I see folks that have been active for a
while contributing to each?
Did Donald mention anything about take-3 and interactions with me?
I read this as allowing for Paul's approach given his long role in the
project, but doing so in a way that allows the community to change
based on community consensus. I personally think a single definitive
quagga release that comes out 2 or 3 times a year would be preferred,
but my understanding is that you vetoed this.
I've sent you private email before on the release history of Quagga,
showing that I like cutting development releases at least as often as
others if not more.
Also, my approach is _not_ "yearly stable" releases. The lack of
knowledge of the history of the project is amusing. Further, having two
disconnected Quagga branches, with releases of each is - I strongly
suspect - unworkable. It will just lead to further problems and
disagreement.
I'm not tracking the drafts as closely as some, but I don't recall
seeing any changes or comments in the google docs from you (or for
that matter on this list).
I'm sure I set out some objections to you in private email before. At
least some of which I'd given to Donald too, or at least on list I
think.
Further, the entire process seemed to be about getting space from me.
So, why would I participate in it?
regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
"Laugh while you can, monkey-boy."
-- Dr. Emilio Lizardo
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
