On 27 Jun 2016, at 2:54, Paul Jakma wrote:
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 difference is between a automated ‘proposed’ tree (no manual
ACK) and
a tree with patches which have been ACK’ed by at least one other
person.
Your suggested way may work partially - but it’s still not clear on
how
things move from that proposed to the master (I just use “master” as
the
main development tree. I do NOT imply that this has to be the master
branch.
I could be another branch, but “master” for development seems to be
common)
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.
It would be less than the ‘proposed’ tree you suggest. But yes,
reverting
or fixing previous commits might happen. Hopefully not too many times if
the
people who send a ACK get used to do some decent code review. But
nothing stops
us to modify the rule later if the quality of the ACKs are not good
enough.
Also, at the same time anyone can send a NACK - which would stop the
patch to
go in until the NACK is either resolved or (in the current proposed
maintainer doc)
agreed by the maintainers.
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.
DPDK is an example
Some of this (not all) came from a discussion I had with Vincent. There
is
an alternative version of the maintainer doc (which we discussed at the
last
call as well) which describes his suggestion (based mostly on DPDK where
he
is involved)
During the discussion it was then mostly voted down based on the
restrictions
of “maintainers” not being allowed to make decisions (separating the
git
mechanics from the decision making) and some thoughts that this may not
work
for a community this small.
We might still get back to this decision if someone figures out to
combine
the 2 models.
Beside, your (or the current widely understood model) is that patches go
it
if there is no NACK - so no active code review or any ACK required.
So this is nearly the same, just now REQUIRING an ACK. A single NACK is
still
stopping the whole process until resolved or overruled by some group
(the
maintainers in the current version)
I honestly fail to see how you think that this is making it worse.
If your only suggestion is to wait a min of 3, 7 or 14 days after an
ACK, then
this can certainly be discussed.
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?
Very few. I agree. I think this is a problem, you seem to be ok on it
(unless I misunderstand)
Having contributors need to push others for a review will only work if
they spend some time
reviewing patches from others as well. I think that’s the beauty on
this.
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.
Scaling issue at this time? Sorry, my feeling is that we don’t have
enough
_full_ maintainers today with the time to be involved. Only you seem to
be
regularly active (again).
I think it needs a certain number of regularly active maintainers, i.e.
3..5 minimum.
As for "your ok" - have you not missed that anyone can object to
patches?
No. But you made it clear that you have the final say (as a maintainer).
And anyone sending a ACK doesn’t seem to trigger any action of the
patch
moving forward - at least that’s the impression.
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).
It’s not just Cumulus.
There are various other groups who tried to push small (and large) fixes
into Quagga and got
rejected.
But Cumulus did some really good enhancements and fixes to Quagga. Their
patches might
not be perfect (i.e. cases for non-linux systems like *BSD), but I think
the good stuff
fairly outweighs the not so perfect or broken part by a wide margin.
Nobody says that it
needs to be released unchanged. By blocking based on some non-perfect
commits, we are
blocking all the good stuff they did at a later stage.
With all the good stuff now missing, I personally would rather open the
floodgates, get
their stuff in and then start working on fixes/improvements on their
code with further
commits. This would allow anyone to send improvements for the Cumulus
code and not just
Cumulus themselves. But this is just my personal opinion. (and you can
fairly claim that
I’m biased as Cumulus is one of the NetDEF/OSR sponsors)
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.
There are at least another choices: You could reconsider. I rather have
just one community
and have all the parties working together.
This community isn’t just you. Yes, you’ve started Quagga and yes,
you own some of the
essential resources (i.e. domain name), but there are countless people
which contributed
or tried to contribute in the hope to move this project forward. I do
believe they should
have a voice as well.
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.
My way or the highway seems to be your view… Sad.
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.
You’ve started a different way (introduced the proposed branches),
then handed it over to
Donald, stepped back into inactivity, didn’t ack him as full
maintainer to allow making
decisions and now blaming him?
Did I get this right?
I think he did an awesome job.
But he is only one person and he had to work on 2 branches (the public
and
the internal cumulus). I would assume you understand the strain as I
assume
you work currently on 2 branches as well (public quagga and HP version)
And he didn’t try to push the Cumulus branch in - at least not yet.
But
I can see his frustration dealing with problems which he has long fixed
in the cumulus internal branch - but he is blocked by pushing this into
the community edition because some commits which you disagree on.
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?
Thanks for the summary, but to be honest, I thought we are talking
about governance, not actual patches.
All the proposed scenarios allow to NACK patches and discuss them.
The current proposed maintainer even requires a ACK by a 2rd party
for it to move forward.
What may change is (in the current proposed maintainer doc) that you
can’t VETO it anymore, but the maintainers together in a collective
can still decide against it if any NACK (from maintainer or not) is
not resolved first.
The key is that in cases of a failure to come to an agreement of the
community (this includes the maintainers as well), then it is voted
over by all the maintainers and a reason needs to be given in case of
a NACK.
- 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).
There are 2 issues here:
1) Backlog
How to deal with Backlog may require a special exception. At least I
can’t
think about any reasonable way to review the large amount of the backlog
just from Cumulus alone. This is obviously something which can and
should
be discussed in the community. There is risk in it (i.e., I’m sure it
introduces new bugs), but personally I think the benefits of all their
improvements may a good thing overall. And none says that it requires to
immediately push for a release afterwards. Patches to fix/improve on
top of this can be worked on (by Cumulus and outsiders)
But again, I think it’s nothing but fair at this time for them to
suggest this and the community to discuss it they want to make an
exception
2) New submissions
If we can’t speed up the review cycle, then this situation will happen
again and again. The maintainer (and tools and community) doc try to
address
these shortcomings.
- 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.
Not random participant. These were all people who follow quagga-dev and
were interested in this discussion on how to improve the community.
Additionally, the documents went through multiple cycles and some of the
part has changed. If you would take the time to actually read the
current
version, then you’ll notice that vote moved from google hangout
participants
to maintainers (and all maintainers - incl the ones not on call who
would
vote on it afterwards on the list)
- 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.
You seem to like picking on Donald. He is only one of the community
members which would like to fix the process.
My impression was that everyone (except you) wants change. The correct
way on the change is still up for discussion, but I think the various
calls and discussions on the list helped to improve the documents and
we are getting close to something agreeable by everyone (except you).
That's not the project I want.
If that's the project other people want, I believe they should fork.
I highly regard people for trying to fix existing processes first
without
just forking. It doesn’t help if we spread the community to various
projects.
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.
You missed the updates. We moved from making decisions to discussions
and resolving differences
(as far as possible).
Decision is still done on the list (at least for the ones not attending
the call, they are
encouraged to review and comment on it after the call).
However, it speeds up sorting the differences over the slower email. So
I think
this helps to get to a agreeable solution.
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.
The part of “authoritative”, I’ve already explained a few times
above. It’s not
(anymore - in current version of the docs)
If I calculate it correctly, then this is around 9pm for China (at least
some
of it). I think that’s acceptable.
I have yet to see Donald follow my suggestion to schedule one of
these
meetings at 0300 his local time.
I would prefer 03:00 at my timezone. Way better than 06:00 as it is in
US pacific timezone now. But I think the time is a good compromise to
get
most people to attend. And until we have people in Hawaii (or somewhere
else in the middle of pacific) attending or wanting to attend, then it
should work somehow for most.
- 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).
So far, only one person mentioned that he is blocked (I believe
Olivier),
but he got it somehow sorted out.
We are not fixed to Google Hangout. We could also use things like
http://appear.in
and we can always change if someone can’t solve the problem. The nice
thing
with Hangout is that we can easily add a free phone bridge and I’m
happy to
even call out and bridge people in by phone if needed.
Google Hangout allows this.
Again, we can discuss alternatives if someone gets excluded because of
it.
At this time, this doesn’t seem to be the case.
- 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.
What’s wrong to discuss things in person? It’s only a benefit,
doesn’t need
to exclude emails. You are aware that summaries of the discussions are
mailed
to the list and discussion can go on by email?
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.
Again, you are saying that you are unwilling to discuss any changes…
Sad.
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 was asking about comments on the maintainer/process/tools document.
I’m aware of the technical arguments.
Regards,
Martin Winter
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
