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 09:11:11 GMT
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.smits@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 <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