community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <pierre.sm...@gmail.com>
Subject Re: Veto! Veto?
Date Tue, 24 Mar 2015 08:59:02 GMT
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 <mkienenb@gmail.com>
wrote:

> On Mon, Mar 23, 2015 at 1:31 PM, Ted Dunning <ted.dunning@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message