On Mon, 27 Jun 2016, Lou Berger wrote:
Thanks -- glad to see you're not singling me out ;-)
Grumpy old gits like me are happy to direct their ire widely, don't
worry. ;)
I don't think I'm the only one that cares about this -- if I am, I'll
shut up and leave the list in peace.
I'm sure lots are interested.
The way to making things better is to tease out each strand of a knotty
problem and solve it, and iterate that process. Analyse what's there,
find something make to better, do it, rinse, repeat.
It could be some prefer revolution, and that's fine. They could be
right. However, given that most of what I saw before in that document is
pretty close to how things should be anyway and *used to be*, it seems
to me revolution is not the answer.
Again, if there was a document to diff against, we could do this -- but
there isn't one!
So just write up the current process. It doesn't take long to look
through the list to find what's been happening, surely? Hell, as before,
'gitk --all' or the 'refs' URI of the git i'face should give a good
clue? (Least, that was the intention).
Just the fact one must have a Google account to participate in this
suggests this is far from an evolution.
This is incorrect - all one needs is a browser. To demonstrate, I made
the above changes without using any google account.
I didn't realise that was now possible. Used to not be the case with a
lot of GOOG products.
Note, I have a GOOG a/c. My email is one there. I don't have any issue
with it. It's just I *know* there are people who absolutely will not go
near GOOG accounts who have been involved in Quagga. Then there's the
issue of them being blocked in places.
- Contributors can game (consciously or not) things by simply ignoring
comments for nearly 2 years, then rally others to vote in their
changes en bloc with talk about how the development process is broken,
_failing to mention_ how they helped break it.
I agree this is wrong.
That's what's annoying me the most.
- Any old crap goes into master, just if whatever random 'Acks'
(completely immune to gaming is that!), and anyone who might have
views just happens to have taken even a brief holiday (cause,
holidays, who needs those).
I'm not sure how to deal with this -- if a patch is updated and
resubmitted it's discussed by those participating. Personally I like
a model of 5+ maintainers and one maintainer ack is required for
inclusion in mainline.
Doesn't sound wrong as such. Though, a pipe-line with a fast-path that
doesn't require explicit action for stuff to go in would be better - or
things can fall through cracks. Plus, sufficient time for people to
object.
E.g., I'd have no objections to an automatically collated head of
submissions, that was fast-fowardable from 'master'. A submission that
applies to whatever that head is at, goes on. Then have 'master'
automatically advance to that head minus X time.
I.e. a completely automated fast-path. Why do we even need manual emails
of "Ack" and people to have to manually apply those things?
The thing I want is to be able to kick things off the fast-path and
require nits addressed or architectural issues discussed.
(Note I say mainline, which may or may not differ from master.)
Well, that's just a facet of the "get around paul's comments" thing
AFAICT.
I think fixing the (lack of) maintainers issue ASAP would benefit us all.
To the extent that 'maintainer' is an integration role, that can be
fixed fairly quickly. It doesn't take much to establish someone can have
a go at that.
To the extent that the 'maintainers' are about final technical
arbitration, I think that should be reserved to a subset of the
community.
To the extent that the 'maintainers' are about governance over wider
issues, I think that should be reserved to another subset (probably
smaller, maybe disjoint).
Let's fix the easy one first, cause the latter two I think will take
longer. If people want to fix all of these in one go, it will just be
harder to get agreement.
As the domain owner
Domain owner, I've had kind of had discussions on that and what not.
Seems hard to address that in a low-overhead way. E.g., a body corporate
of any kind would need lots of discussions. Not sure it's a good idea to
start off on that now.
The simplest way - in the short-term - is just for me to make a will and
name a trustee to manage it in the (hopefully unlikely) event of
something happening to me, and figure out how to get it into some
community controlled vehicle. I know of a person or two who might be
good choices, who I'd trust to act in the widest interest, in such an
unfortunate event.
I genuinely appreciate you engaging in this (IMO painful and unwanted)
discussion. I really do believe that *everyone* is interested in the
same thing: an inclusive, successful and vibrant quagga.
Well, no doubt.
I think a lot of the issues get easier to fix by separating the issues
as much as possible. And each strand fixed will make it easier for
everyone else to get along.
The Cumulus backlog, the easiest way to fix that is to get through it -
and a good chunk of it should just go straight in. The rest, just bash
at the nits and bash at the arch. discussions on the remainder.
Then we get on to the other stuff pending - the VPN stuff (btw, design
documentatoin? kudos), etc.
Keep bashing away at the technical stuff - the stuff networking geeks
are good at bashing away at - and a lot of this gets easier.
regards,
--
Paul Jakma | [email protected] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Go away, I'm all right.
-- H.G. Wells' last words.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
