Hi Vincent / all,
The doc contains a few main points. Some more clear than others. Here
are some comments on how I read it, both for ensuring I understand you
correctly, and for discussion:
1. Steering committee and new maintainers roles and election
The doc doesn't say how maintainers are appointed / elected.
I have no objection to the new definitions.
2. Review of patches
There is no obligation on anyone to take on review of a patch.
I think this is needed to ensure a vibrant quagga. I think review
should be one of the requirements for being on the steering
committee, and as a backup for when reviews are not done by others.
3. Dispute resolution
Falls to steering committee. I think is fine as long as dispute
discussions take place in public (e.g., on list, public meetings ) and
decisions are always reviewed on list.
4. Ack’ed code
Goes to a development branch. This is great and one of the
main things not happening in a timely fashion today.
I also think the development branch should always be in
the same place -- master makes sense to me but
*any stable place* would be a huge improvement.
4. Release process/cycle
I think this is largely a separable discussion than the above. Also I
found the text a bit vague and confusing. I suggest moving/combining
this with the other process doc and discussing separately.
If I correctly interpret what you're saying, I think the process itself
is fine assuming it is coupled with a fixed release schedule, e.g.,
per CE.
Thanks,
Lou
On June 21, 2016 3:20:32 AM Vincent JARDIN <vincent.jar...@6wind.com> wrote:
>
> Thanks Martin.
>
> It is a good summary.
> Le 21 juin 2016 05:14, "Martin Winter" <mwin...@opensourcerouting.org>
a écrit :
>
> 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
>
> _______________________________________________
> 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
