Thanks Martin. It is a good summary. Le 21 juin 2016 05:14, "Martin Winter" <[email protected]> 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 >>> [email protected] >>> https://lists.quagga.net/mailman/listinfo/quagga-dev >>> >> >> >> >> _______________________________________________ >> Quagga-dev mailing list >> [email protected] >> https://lists.quagga.net/mailman/listinfo/quagga-dev >> > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
