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