On 27 Jun 2016, at 5:22, Paul Jakma wrote:
[any 'you' in the below may be general case than you specifically]
On Mon, 27 Jun 2016, Lou Berger wrote:
In terms of specific development processes, things have evolved and
should continue to evolve.
Why is this recent discussion anything than an evolution of the
process?
If it's meant to be evolution, show me the evolutionary path? Give me
a "diff" from the current processes to what is being proposed?
I assume you mean a diff to the current process:
I think the attempt here started with some suggestion with a disregard
of existing process and
then over multiple stages of discussion go and adapt it to current
process. Just a different
process, but still the end product (or better: the current suggestion)
is not completely different.
It’s actually only different on a few sections. (i.e. the maintainer
doc on adding rules of
removing maintainers based on inactivity among a few other things)
Just the fact one must have a Google account to participate in this
suggests this is far from an evolution.
You don’t need a google account. The documents are shared on Google,
but anyone can access them
without logging into Google and edit/comment on them.
For the phone calls: You don’t need a google account either. Anyone
can join the calls with whatever
email they get the invite on or just by getting the link forwarded to
them. (Unless Donald didn’t
by accident allow this)
But yes, you need access to google.
But again, unless there is someone having an actual issue, then there is
no need to move. (Other tools
have other limitations). We could move the docs to a Wiki if needed,
calls to any other service.
Nobody insisted to this on Google.
I accept that there may not be as much understand and context of
quagga's history as think there should be. But if those that have the
history or are not participating in the discussion , that history
will be missed. While this isn't preferred, we can't compel people to
participate.
That's a 2-way street.
And it has seemed to have left you somewhat abandoned by the other
"maintainers".
Look, it really gives me _no_ joy to make other people unhappy.
Honestly. I _want_ you to be happy, and if you want a project where:
- Decisions are made by Google Hangouts at a time that suits US TZ
I think it suits europe better at the usual monthly 13:00 GMT time.
(and that’s fair as I have the feeling that most participants are
in europe)
But there are no final decisions. They are discussions.
- 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.
And maintainers can veto things just because they don’t like it (i.e.
I can
do it better, but I don’t have the time for it, so VETO) or force
lengthy
discussions over ideas on improving the RFCs and breaking compatibility.
This does not encourage any participation…
- 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).
[the goal of reducing rebases is a good one, and fast cycles and
auto-collated proposed trees would help with that, but some of what
I've read so far is just "I want magic ponies!" in that regard]
If you prefer things to go in if there is NO voice (no ACK, no NACK)
like it should be now, then please explain how this is better.
I think a random ACK is still better.
And it seems to work for some other communities.
Then _please_ go set up that project. I'm _*begging*_ you. _How clear
do I have to be?_
Really, we'll _all_ be happier.
You really seem to be unwilling to move from your positions and rather
break the community in 2 (or more parts).
Sad.
- Martin Winter
Me, I'm going to:
- Keep going through the last of the backlog, and sort it out.
- Get the obvious stuff in ASAP, get nits pushed back ASAP to the
contributors so they can fix them, and derail stuff that needs wider
discussion (and sorry that just happens in distributed,
decentralised
development sometimes - people just /happen/ to pull in different
directions, and it needs resolving; and the outcome can mean
significant reworking or even lost work; it happens, it happens to
me].
- Listen to people's comments on patches, including my own. I manage
to
listen to other people's opinions on my patches - I might not like
the
comments or agree with them. I don't see why this is a problem in a
well functioning community.
- Find people willing to help constructively, who are willing to work
to
consensus
[that can mean going with majority opinion usually, but still
respecting people when there's something they really don't get on
with
- e.g. like trying to push binding majority votes through, in order
to
try get around comments on a series of their patches].
I'm more than willing to share Quagga with others. The people involved
- including in maintainer/governance/roles has generally increased
while I've been active.
All I ask is that we share on a mutually agreeable basis.
If that seems unreasonable to anyone:
The door is -------------> that way.
I'll be sad, I'll wish them well, I'll hope to still be able to
collaborate with any such person in the future to some degree.
However, if we can't agree on that fundamental parameter then THIS IS
NOT THE PROJECT FOR SUCH PEOPLE, and it is _better for all of us_ if
we go to separate projects where we won't have to butt heads as much.
regards,
--
Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Avec!
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
