A little bit late, but I had a long call with Vincent today (his late
monday evening).
He has some different suggestion which I wrote down in a new document as
an alternative choice. (Unfortunately, he can’t attend the call)
Description is here:
https://docs.google.com/document/d/1A0kr7PrlsXs7Xe4btAgVWolvXYF5-JjtSWTOQypGRSs/edit?usp=sharing
Key changes:
- Maintainers are reduced to git committers and can’t make the
ACK/NACK
decision.
- Anyone in community can ACK/NACK a patch.
- No ACK: does not go in at all
- Can’t agree: will get pushed to Steering committee for decision
- Dispute resolution is done by a Steering committee which is elected
I hope I got all the details correctly written down in the spirit of how
Vincent explained it to me.
- Martin
Disclaimer: I’m only the person who wrote it down. This does not mean
that
I agree or disagree on it. But I want this choice to be discussed as
well.
On 18 Jun 2016, at 14:23, Lou Berger wrote:
On 6/14/2016 12:55 PM, Donald Sharp wrote:
Next Tuesday we have the normal monthly meeting. If you have
anything
that you would like to discuss please let me know so I can add it to
the agenda.
I'd like to discuss and vote on the 3 documents:
Maintainer:
https://docs.google.com/document/d/19DZcT0cJUSYxVIFenHvGFhLLUmLTRFHuMNZcI7aUNGA/edit?usp=sharing
I made a few minor changes and comments. The most substantive change I
made was to clarify that missing e-mail votes are the ones that count,
and that it's 3 out of 6 votes is needed to be inactive (3 in a row, 3
out of 4, 3 out of 5, and 3 out of 6 all = inactive).
It looks good to me (either with or without the changes). I vote yes
(as contributor).
Tools:
https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing
I think the document combines a few things together in a few places,
e.g., submission within the code review section. I suggested some
changes to address this. I think the topic of submissions via pull
requests is also missing. From my contributor perspective, I prefer
pull requests makes the most sense, but given where the project is
"vote" for both email patches and pull requests. Having pull requests
only be mandatory for patch sets seems like a reasonable transition
approach...
This too looks good to me (either with or without the changes). I vote
yes (as contributor).
Quagga Process:
https://docs.google.com/document/d/1xYrpTKYDvK23BCxXP-dbE6nOuvBxbGIilNLfVkI3j-I/edit?usp=sharing
I support this new process. I tweaked the language related to
confirming meeting decisions on the e-mail list. The main point of the
change is that split decisions (those that are not unanimous across
all
maintainers) need to be confirmed on the list and and all decisions
are
announced on the list.
I'm particularity interested in (and see this as the most important
part
of the overall discussion):
(a) having an active master branch that reflects the current/living
state of ACK'ed patches
(b) having a predictable release cycle
Lou
PS I'm unlikely to be on the whole call on Tuesday due to an
unavoidable
conflict -- but I hope the above unambiguously provides my position.
Please take the time to read/discuss.
thanks!
donald
_______________________________________________
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
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
https://lists.quagga.net/mailman/listinfo/quagga-dev
