Now that we have that cleared up, we can all go back to our projects and contribute the good stuff to our works.
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Tue, Mar 24, 2015 at 9:59 AM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Having reread the earlier postings I summarise what has been said it as > this: > > > - No vetoes are allowed, when it comes down to procedural issues > (electing persons into functions, e.g. committer, PMC Member, PMC Chair, > etc). > - As stated by Bertrand in his remark that 'A positive result is > achieved by Consensus Approval i.e. at least 3 +1 votes and no vetoes' > in > https://community.apache.org/newcommitter.html wrong, because > https://www.apache.org/foundation/voting.html states that voting on > procedural issues follow the common majority rule > > I wonder how many projects have stated in their policy (rules of > the games) pages, that they do it differently. > I also wonder how often it happened that - for the projects that > don't state that they do it differently - the common majority rule > wasn't > applied when it came to voting regarding a potential committer or PMC > Member. > > - Unanimity = consensus wrt procedural issues, as all are for > either for or against what has been voted on. Consensus wrt code-changes > means no vetoes. > > - As far as the ASF and the board is concerned, any project under the > ASF umbrella can have the policies its wants/needs and the board is not > going to police that. > - Interpreting the statements made by Rich. > - However the https://www.apache.org/foundations/voting.html is > contradicting that statement in the section about binding votes. > > > - The statement made by Rich can be interpreted as that a > project can even deviate from any statement made in the voting.html > page as > these statements are suggestions based on some kind of arbitrary best > practices. As examples: > - if you want in your project to have it that all contributors > with signed, sent and accepted iCLAs can vote once per year on new > committers and PMC members, then that is acceptable by the ASF and > the > board. > - If you want in your project to have it that all contributors > active for 1 year or more can directly vote the PMC Chair every three > years, than that is acceptable by the ASF and the board. > - If you want to have the policy in your project whereby you > want to exclude contributor 'of the other kind' from positions in the > project (committer, PMC Member, PMC Chair), then that is acceptable > by the > ASF and the board. > > > > Best regards, > > > > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Mon, Mar 23, 2015 at 6:41 PM, Mike Kienenberger <mkien...@gmail.com> > wrote: > >> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <ted.dunn...@gmail.com> >> wrote: >> >> > > Here's a better not-quite-so-hypothetical example. A project like >> > MyFaces >> > > has to pass the TCK testing suite provided by Oracle. We would not >> want >> > > to allow unrestricted commit access by someone who did not >> > > understand profoundly and intuitively that the JSF API portion of the >> > > project has a predefined public API which cannot be changed. >> > >> > >> > Some projects feel this way. Others have found that review is just as >> > effective as restricting commit bits tightly. The classic case is >> > Subversion which has a very high profile (and thus is obliged to have >> > stable API's). That PMC offers a commit bit to anyone who asks. >> > >> > People seem to forget that erroneous commits that pass review can >> simply be >> > reverted. That is one of the points of using version control. >> > >> >> Yes, either approach could be used. Myfaces doesn't filter candidates >> based on this criteria -- we train contributers when they submit their >> first patches to the API project -- but a TCK project might decide to do >> so. The message probably should have read "They might not want to allow" >> rather than "We would not want to allow " as it gave the wrong impression. >> > >
