On Sat, 25 Jun 2016, Martin Winter wrote:
Strongly support this.
I really think that things need to move from ACK into the master
(or whatever the development branch is) in matter of days. This would
make integration (and testing) much simpler: Further contribution would
be tested on top of the development branch and it would be much more
clear when/what broke - and give more people time to test against the
growing development tree.
This is why I've been suggesting an auto-collated 'proposed' tree.
The current model of “proposed trees” just doesn’t work. It was a fair
try, but I think we now have enough evidence to improve the process.
What you're proposing is to make 'master' the 'proposed' tree though - a
couple of days is just not enough time to give interested parties the
chance to look at a patch, if this 'ACK' can come from anyone. Except,
we can never 'master', so its history would become full of trivial edits
and reverts.
I don't know any other project that guarantees contributions go in to
the main integration head within days, on the say so of one other random
ACK.
I think most of this is based (at least) on confusion. Most people
think that you only look at yourself, Vincent and Greg as actual
maintainers and the rest (i.e. Donald) as sub-maintainers or “round
keepers” without the right on merging into master without your ok.
This is not encouraging their work.
My experience is that people who contribute stuff aren't per se
interested in helping with integrating other people's stuff. They have
their own concerns and stuff they're getting on with, they don't per se
have time to follow along with what other people are doing (except to
extent it might impact stuff they're working on). And _that's fine_!
E.g., how many people regularly help review other contributions?
The best indication that someone is interested on the integration side -
I've found in the past - is when they're regularly doing that stuff.
Helping with reviews, integrating patches, etc.
On roundskeeper v maintainer, that's something where I was trying to
nudge things into evolving. Historically, governance and integration
have all been rolled up into one - 'maintainer', but I'm not sure that
scales per se. It'd be better to separate the roles.
As for "your ok" - have you not missed that anyone can object to
patches?
It might not be perfect on the first try, but at least a group of
active contributors would like to give it a new try.
The main differentiating feature seems to be "vote stuff, so that
Cumulus can shove take-3 and ignore Paul's comments - several of which
he made to Cumulus in **2014**" (as you should know).
If that's what wanted, then that's not the community for me.
And if it's not the community for me, then we have a constitutional
crisis which can only be resolved by one set of people forking and going
elsewhere.
I would submit that the onus is not on me to fork.
If people really don't want to find ways to deal with my comments, this
is not the project for them.
And deliberately engineering a crisis by blocking integration of patches
(again, we were *forward-caught-up* with the patchwork backlog when I
handed over integration to Donald late last year. Donald *chose* to stop
generally integrating stuff for r7, because he decided to hold
integration hostage to having take-3 integrated as is), then working on
documents that largely _fail_ to address any problem we have, is, I
would submit, a crappy way to deal with getting the backlog done and
dusted.
Some here. I see a lot of them just documenting the existing way (at
least as I think it is right now). Only a few changes to actual work.
Yes, indeed.
The main change has not been very explicitly described:
- I was trying early this year to work through Cumulus' take-3 backlog
with Donald. We seemed to be getting somewhere. Many patches are fine.
Some patches just need trivial things addressed, like setting
'--author=Piotr' on the tags patches as those patches appear to be
substantively his work and it's still trivial to do (and whatever my
own views, I'm going to be super-attentive to stuff like that, given
the past).
Some patches seem not quite polished, e.g. the table-map stuff just
copies BGP objects and ignores ref-counting.
Some patches are cool, but have some significant UI issues, though
probably easily resolved. E.g. the route-map automatic reprocessing
stuff is really cool, but the event that triggers reprocessing is a
timer. That seems strange. Some kind of more explicit event would
probably be better - e.g. leaving config mode. I had a conversation
with Donald on this, I thought we were agreed.
Some patches come with architectural concerns. E.g. queueing of work
in BGP. There's a number of these. As I did the original queueing
work, I have opinions about this. In retrospect, it didn't deliver as
many benefits as I'd hoped for, while it does tend to introduce or
uncover bugs (e.g. in lifetime management of objects). It also adds
overhead. The Cumulus patches don't really come with measurements of
their benefit, so hard to say. Further, they come with more patches to
add further heuristics to try manage queues further. I think we need a
wider discussion on strategy on managing work in BGP, before going
further down the path of adding more and more queueing complexity.
MED: I'm a bit resistant to encouraging something deeply problematic.
We need to acknowledge that MED - as specified - is br0ken. The goal
was useful, however the subtleties were not understood at the time. It
is intrinsically incompatible with basic {Distance,Path}-Vector
routing - there's just no arguing with the mathematics of fields and
graph theory that since clearly show this.
So, before we try add code that either encourages admins to use it
(e.g. max-med commands), or add code that adds intrinsic overheads
(like having no choice but to to do O(nlogn) comparisons in the RIB,
instead of O(n); having to communicate potentially exponential
greater numbers of BGP UPDATEs), we should take a step back and ask
if MED is worth this. How much overhead is it worth to make this "pig"
fly?
- I tried to work with Donald through this earlier this year. I helped
rebase take-3, I gave him a bunch of reviews. I thought we were going
to keep plugging away at that, get all the good-to-go stuff in and
address the other issues.
- Donald then turned a bit towards advancing an argument that take-3
should just go in as is. That it had been around so long, there should
be no more discussion. Further, that Cumulus is producing patches
faster than they are going in, therefore there must be less discussion
(i.e. the review comments are the problem).
- I disagree a bit with that. I gave comments on a /smaller/ backlog
well over a year ago. Indeed, it's not far off hitting "years". For
whatever reason (resources, stuff just getting lost), those comments
were never addressed. However, I gave the same comments again. They
weren't addressed, instead the same patches get put forward again
and again. Even patches from late last year are there in take-3.
So from my POV, the issue is not engaging (for whatever reason, which
may be quite understandable) with the comments.
Further, to accept Donald's logic, is to accept that contributors
should be *rewarded* for ignoring (for whatever reason) comments. Just
ignore comments long enough, until eventually "they've been around so
long they must go in without comment!"
- Donald was to hand over rounds-keeping to David. David announces the
next round it be based on take-3. Sigh. I point out I have review
comments on that (I assume Donald communicated that to David somehow).
- Next, Donald sat on integrating further work generally. He does the
the next round (r7) with just a few small bugfixes - rather than
queueing up all new patches in patchwork to a 'proposed' head.
- We wait a while, and nothing else happens, except this drama about how
Quagga development isn't working. With documents that are largely
"same but different", except of course with changes going in within 2
weeks or being voted on by any random participant on a Google Hangout.
- As far as I know, at no stage does Donald communicate to others that
the nub of the issue is he wanted take-3 to go in without further
discussion and without addressing my comments - some of which Cumulus
have had nearly *years* to act on.
That's not the project I want.
If that's the project other people want, I believe they should fork.
Now, I understand Cumulus want to get this backlog cleared. Hell, I
really want it cleared, cause I consider it to be blocking more
interesting stuff I want to do. You think I'm getting popularity points
with my employer with "Well, there's this backlog of other people's
stuff that needs to be addressed first I think"?
I think the best way to address that backlog though is to just get on
with reviewing it and sorting it into "get it in", "nits" and "needs
discussion". And a huge chunk of it falls into "get it in".
Paul, you seem to be mostly absent on all the discussion.
And why is that?
Cause when I tried to engage with that discussion, even little practical
things on real-time comms for decisions seemed to be deliberately
ignored.
I know Donald likes video-conferencing to make decisions. Hey, it's not
bad for quickly discussing stuff. However:
- It can't be authoritative, cause no single time will work for everyone
in a project that has people in India, Europe, West and East coast USA
and (I suspect judging just on names) China.
I have yet to see Donald follow my suggestion to schedule one of these
meetings at 0300 his local time.
- Certain big US based tech companies' public networks are either
blocked in some countries (inc. one I happen to visit every other year
or so, and will usually spend at least 2 weeks in when I do), or are
distrusted by others to extent they won't use them (and Quagga does
have or had people who feel that way).
- I like email for more final deliberative stuff.
If someone wants to have an open-source project around this code-base
that uses real-time Google HangOuts for important decisions, they're
welcome to go try that.
However, I'm just not good with that.
So what we try is to make a way which is acceptable to you as well -
giving you some way to continue the existing way while allowing
everyone who is willing to try a new way to do this and see how it
turns out.
The proposal I saw seemed to be about having one tree for me (a "yearly"
stable tree - which shows a hilariously ironic degree of knowledge on
the history of Quagga), and another for others.
I don't think that solves anything. Indeed, it just creates more
problems I suspect. It's a fork. In that case, I suspect we'd just end
up in _further_ hard discussions, increasingly distanced from technical
matters.
If a set of people really don't want to have be bound by my comments,
then they should do the fork properly now. They can go build their own
community that suits them. They can put in whatever commits they like.
They can also pick the commits from Quagga they like, and ignore the
ones they don't. Ditto for Quagga.
We'll all be happier, really.
Why work with people you find troublesome? I honestly don't want anyone
who thinks that of me to have to suffer further so.
Missed them too. Can you point to the email or the comments? I would
mainly be interested on what part you support/are ok with/ or disagree
on each of the documents. And maybe you can even suggest some new
version of the parts you disagree for the community to discuss.
That particular section was talking about my review comments on
Donald/Cumulus' take-3. Which I had sent to him somewhere around March
or April I think. I've summarised some of them above.
I'll summarise them again in the r8 email I send around - which this
stuff is a distraction from getting done.
Comments on the document I'm sure I've made either on that call I was
on, to Lou in private email thereafter, or here on list.
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
You're either part of the solution or part of the problem.
-- Eldridge Cleaver_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
