Re: [VOTE] Enable Release Checklist Experiment

[Henry Saputra]

So it begins =)

+1

Thanks for leading the effort, Marvin

- Henry


On Fri, Dec 13, 2013 at 12:59 PM, Marvin Humphrey
 wrote:
> Greetings,
>
> As the next step in our ongoing efforts to reform the release voting process,
> I propose that we run an experiment allowing the PPMC members of select
> podlings to earn binding votes under limited circumstances by completing a
> release checklist.
>
> For participating podlings, the Incubator's release management guide...
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> ... would be supplanted by the following documents:
>
> http://incubator.apache.org/guides/release_manifest.txt
> http://incubator.apache.org/guides/release.html
>
> The scope of this VOTE is limited to approving the following patch to our
> policy page:
>
> https://paste.apache.org/k4vJ
>
> Here is the patch content minus markup:
>
> 2013 Alternate Release Voting Process
>
> Select podlings pre-cleared by a majority vote of the IPMC MAY
> participate in
> an alternate release voting process:
>
> Should a Podling decide it wishes to perform a release, the Podling SHALL
> hold a vote on the Podling's dev list and create a permanently archived
> Release Manifest as described in the Experimental Release Guide.  At least
> three +1 votes from PPMC members are required (see the Apache Voting
> Process page).  If the majority of PPMC votes is positive, then the 
> Podling
> SHALL send a summary of that vote to the Incubator's general list and
> formally request the Incubator PMC approve such a release.
>
> Formal approval requires three binding +1 votes and more positive than
> negative votes.  Votes cast by members of the Incubator PMC are always
> binding.  For all releases after the first, votes cast by members
> of the PPMC
> are binding if a Mentor approves the Release Manifest.
>
> Please note that the proposed change is both incremental and reversible:
>
> *   It is incremental because podlings must be opted in by vote of the IPMC to
> participate.
> *   It is reversible because once the experiment has run its course the
> policy change can be reverted with zero impact through lazy consensus.
>
> Those who may have questions about the legitimacy of allowing binding votes
> from non-IPMC members should see this post from Roy Fielding:
>
> http://s.apache.org/v7
>
> Please vote:
>
> [ ] +1 Yes, apply the patch enabling the experiment.
> [ ] -1 No, do not apply the patch enabling the experiment.
>
> This majority VOTE will run for 7 days and will close at 13:00 PST on Friday,
> December 20, 2013.  Votes cast by members of the Incubator PMC are binding.
>
> Here is my own +1.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Spark 0.8.0-incubating (rc4)

[Patrick Wendell]

Please vote on releasing the following candidate as Apache Spark
(incubating) version 0.8.1.

The tag to be voted on is v0.8.1-incubating (commit b87d31d):
https://git-wip-us.apache.org/repos/asf/incubator-spark/repo?p=incubator-spark.git;a=commit;h=b87d31dd8eb4b4e47c0138e9242d0dd6922c8c4e

The release files, including signatures, digests, etc can be found at:
http://people.apache.org/~pwendell/spark-0.8.1-incubating-rc4/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/pwendell.asc

The staging repository for this release can be found at:
https://repository.apache.org/content/repositories/orgapachespark-040/

The documentation corresponding to this release can be found at:
http://people.apache.org/~pwendell/spark-0.8.1-incubating-rc4-docs/

For information about the contents of this release see:
https://git-wip-us.apache.org/repos/asf?p=incubator-spark.git;a=blob;f=CHANGES.txt;h=ce0aeab524505b63c7999e0371157ac2def6fe1c;hb=branch-0.8

A vote on this release has passed within the Spark PPMC [1].

Please vote on releasing this package as Apache Spark 0.8.1-incubating!

The vote is open until Tuesday, December 17th at 03:30 UTC and
passes if a majority of at least 3 +1 IPMC votes are cast.

[ ] +1 Release this package as Apache Spark 0.8.1-incubating
[ ] -1 Do not release this package because ...

To learn more about Apache Spark, please see
http://spark.incubator.apache.org/

[1]
http://mail-archives.apache.org/mod_mbox/incubator-spark-dev/201312.mbox/%3CCABPQxsuEYMn_JE0qEOcrt4J5-N1PJWgGcN7m0qzNefW7fsz2PA%40mail.gmail.com%3E

(Note that at present the concluding message isn't shown due to lag in the
mail archives.)

Re: Release Verification Checklist

[sebb]

Just discovered another important aspect of a release that is often overlooked.

The current source release artifacts must be released via the ASF
mirroring system.
Download pages must not point directly to the ASF servers; they must
use the mirror CGI scripts
Also old releases must not be left on the mirroring system; any
download links must use the ASF archive server.
The download pages must also include links to sigs and hashes and the
KEYS file, all of which must be on the ASF servers (not via mirrors).

There were at least two recent graduations that do (did) not follow these rules.
One provided links to the SVN dist/release area, the other links
directly to www.apache.org/dist


On 13 December 2013 17:48, ant elder  wrote:
> The N word wasn't particularly helpful or constructive, sorry. I do think
> the policy page should be kept simple and generic though, so isn't the
> place to be describing this experiment.
>
>...ant
>
>
> On Fri, Dec 13, 2013 at 3:39 PM, ant elder  wrote:
>
>> Well sorry but IMHO thats nonsense. The Maven decision was an isolated
>> incident and didn't change the way all future Incubator policy should
>> get decided. Insisting that this experiment is done via a change to
>> the main policy just makes it contentious when it doesn't need to be.
>> All the complexity in the language and approach, the three votes etc
>> is exactly why people get the idea that the ASF is a ridiculous place
>> with overbearing rules and process. Its just an experiment, use lazy
>> majority consensus and go try it with a podling.
>>
>>...ant
>>
>> On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey 
>> wrote:
>> > On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
>> >> I'm also opposed to updating the policy document, so will be voting
>> against
>> >> this just for that.  Its just an experiment so you don't need to be
>> making a
>> >> permanent change to the policy page to try it, especially as its such a
>> >> clunky convoluted change.
>> >
>> > An explicit policy change is required because otherwise there would be
>> > ambiguity as to whether a release which passes under the modified regime
>> is an
>> > act of the Foundation and confers indemnity on the Release Manager.
>> >
>> > The language of the proposed change to the Policy page has been carefully
>> > composed.  It is highly isolated from the rest of our policy and has no
>> force
>> > except on the the experiment.
>> >
>> > This proposal is structured as an incremental, reversible change.  It is
>> > incremental because podlings must be opted in by vote of the IPMC to
>> > participate.  It is reversible because once the experiment has run its
>> course
>> > the relevant section of the policy page can be removed with zero impact
>> > through lazy consensus.
>> >
>> >> (And responding to another related comment in the thread - since when
>> have
>> >> policy updates not required consensus?)
>> >
>> > The 2008 proposal to allow distribution through Maven was enacted after a
>> > contentious majority-rule vote passed 15 to 12.
>> >
>> > Marvin Humphrey
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Welcome to the Incubator, new Log4cxx community!

[Marvin Humphrey]

(cross-posted to log4cxx-dev@logging and general@incubator)

Greetings, new Log4cxx community!

For those of you who are new to the Incubator or to the Apache Software
Foundation, here's a short list to help you get oriented:

*   See  for a practical
introduction to the Incubator experience.
*   The mailing list general@incubator.apache.org is our public help desk.
Please feel free to inquire there if you have any questions about either
the Incubator or any aspect of the ASF.  (Subscriptions:
)
*   If you have a question you're not comfortable asking in a public forum
like general@incubator, please feel free to contact one of Log4cxx's
Mentors or any other member of the Incubator PMC.

For general@incubator readers who may want to follow Log4cxx's development,
the subscription address is .

May your stopover here be short and sweet,

Marvin Humphrey
Apache Incubator PMC Chair

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Welcome to the Incubator, Phoenix Community!

[Marvin Humphrey]

(cross-posted to dev@phoenix.incubator and general@incubator)

Greetings, Phoenix community!

For those of you who are new to the Incubator or to the Apache Software
Foundation, here's a short list to help you get oriented:

*   See  for a practical
introduction to the Incubator experience.
*   The mailing list general@incubator.apache.org is our public help desk.
Please feel free to inquire there if you have any questions about either
the Incubator or any aspect of the ASF.  (Subscriptions:
)
*   If you have a question you're not comfortable asking in a public forum
like general@incubator, please feel free to contact one of Phoenix's
Mentors or any other member of the Incubator PMC.

For general@incubator readers who may want to follow Phoenix's development,
the subscription address is .

Please enjoy your stay here,

Marvin Humphrey
Apache Incubator PMC Chair

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Github Permissions for Committers

[Daniel Kulp]

On Dec 13, 2013, at 2:25 PM, P. Taylor Goetz  wrote:

> Thanks for the clarification Jake.
> 
> 
>> There is a very small number of people who have access to the Github Apache
>> organization and they are the ones responsible for managing and maintaing
>> the mirrors. It would be very difficult to deal with the auth on an
>> external system and cross usernames which do not match up and maintaining
>> each projects permissions not only internally but also externally. Also the
>> audit trail for a pull request being granted use to the ASF is not straight
>> forward
> 
> Should we discourage the use of github pull requests for code contributions 
> then? Is there a standard procedure or policy for github vs. JIRA?
> 
> Thanks in advance,

For projects that I’m involved with that have received github pull requests, 
when it’s committed into Apache’s repo, we then comment on the pull request 
something to the effect of:

“We’ve committed this into the Apache repo.  Can you verify that the 
functionality works for you and, if so, close this pull request."

95% of the time, the user that submitted the request will then close it 
themselves.


-- 
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Re: [VOTE] Enable Release Checklist Experiment

[lars hofhansl]

+1



 From: Marvin Humphrey 
To: "general@incubator.apache.org"  
Sent: Friday, December 13, 2013 12:59 PM
Subject: [VOTE] Enable Release Checklist Experiment
 

Greetings,

As the next step in our ongoing efforts to reform the release voting process,
I propose that we run an experiment allowing the PPMC members of select
podlings to earn binding votes under limited circumstances by completing a
release checklist.

For participating podlings, the Incubator's release management guide...

    http://incubator.apache.org/guides/releasemanagement.html

... would be supplanted by the following documents:

    http://incubator.apache.org/guides/release_manifest.txt
    http://incubator.apache.org/guides/release.html

The scope of this VOTE is limited to approving the following patch to our
policy page:

    https://paste.apache.org/k4vJ

Here is the patch content minus markup:

    2013 Alternate Release Voting Process

    Select podlings pre-cleared by a majority vote of the IPMC MAY
participate in
    an alternate release voting process:

    Should a Podling decide it wishes to perform a release, the Podling SHALL
    hold a vote on the Podling's dev list and create a permanently archived
    Release Manifest as described in the Experimental Release Guide.  At least
    three +1 votes from PPMC members are required (see the Apache Voting
    Process page).  If the majority of PPMC votes is positive, then the Podling
    SHALL send a summary of that vote to the Incubator's general list and
    formally request the Incubator PMC approve such a release.

    Formal approval requires three binding +1 votes and more positive than
    negative votes.  Votes cast by members of the Incubator PMC are always
    binding.  For all releases after the first, votes cast by members
of the PPMC
    are binding if a Mentor approves the Release Manifest.

Please note that the proposed change is both incremental and reversible:

*   It is incremental because podlings must be opted in by vote of the IPMC to
    participate.
*   It is reversible because once the experiment has run its course the
    policy change can be reverted with zero impact through lazy consensus.

Those who may have questions about the legitimacy of allowing binding votes
from non-IPMC members should see this post from Roy Fielding:

    http://s.apache.org/v7

Please vote:

[ ] +1 Yes, apply the patch enabling the experiment.
[ ] -1 No, do not apply the patch enabling the experiment.

This majority VOTE will run for 7 days and will close at 13:00 PST on Friday,
December 20, 2013.  Votes cast by members of the Incubator PMC are binding.

Here is my own +1.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Enable Release Checklist Experiment

[Marvin Humphrey]

Greetings,

As the next step in our ongoing efforts to reform the release voting process,
I propose that we run an experiment allowing the PPMC members of select
podlings to earn binding votes under limited circumstances by completing a
release checklist.

For participating podlings, the Incubator's release management guide...

http://incubator.apache.org/guides/releasemanagement.html

... would be supplanted by the following documents:

http://incubator.apache.org/guides/release_manifest.txt
http://incubator.apache.org/guides/release.html

The scope of this VOTE is limited to approving the following patch to our
policy page:

https://paste.apache.org/k4vJ

Here is the patch content minus markup:

2013 Alternate Release Voting Process

Select podlings pre-cleared by a majority vote of the IPMC MAY
participate in
an alternate release voting process:

Should a Podling decide it wishes to perform a release, the Podling SHALL
hold a vote on the Podling's dev list and create a permanently archived
Release Manifest as described in the Experimental Release Guide.  At least
three +1 votes from PPMC members are required (see the Apache Voting
Process page).  If the majority of PPMC votes is positive, then the Podling
SHALL send a summary of that vote to the Incubator's general list and
formally request the Incubator PMC approve such a release.

Formal approval requires three binding +1 votes and more positive than
negative votes.  Votes cast by members of the Incubator PMC are always
binding.  For all releases after the first, votes cast by members
of the PPMC
are binding if a Mentor approves the Release Manifest.

Please note that the proposed change is both incremental and reversible:

*   It is incremental because podlings must be opted in by vote of the IPMC to
participate.
*   It is reversible because once the experiment has run its course the
policy change can be reverted with zero impact through lazy consensus.

Those who may have questions about the legitimacy of allowing binding votes
from non-IPMC members should see this post from Roy Fielding:

http://s.apache.org/v7

Please vote:

[ ] +1 Yes, apply the patch enabling the experiment.
[ ] -1 No, do not apply the patch enabling the experiment.

This majority VOTE will run for 7 days and will close at 13:00 PST on Friday,
December 20, 2013.  Votes cast by members of the Incubator PMC are binding.

Here is my own +1.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Github Permissions for Committers

[Jake Farrell]

There is currently no set standard procedure or policy for Github. Apache
Cordova is the only project that I am aware of that uses Github as a means
for patch ingestion and they require that all contributors have an ICLA on
file and explicitly grant use to the ASF for that submission. Apache
Usergrid (incubating) has recently decided to follow this method as well.

I am personally not a proponent of this workflow and would recommend using
the tools that are currently in place and provided by infra. I have found
it much easier to move from project to project and help across the board
and be able to search, cross link and reference other projects issues
rather than having to leave and use external systems.

-Jake




On Fri, Dec 13, 2013 at 2:25 PM, P. Taylor Goetz  wrote:

> Thanks for the clarification Jake.
>
>
> There is a very small number of people who have access to the Github Apache
> organization and they are the ones responsible for managing and maintaing
> the mirrors. It would be very difficult to deal with the auth on an
> external system and cross usernames which do not match up and maintaining
> each projects permissions not only internally but also externally. Also the
> audit trail for a pull request being granted use to the ASF is not straight
> forward
>
>
> Should we discourage the use of github pull requests for code
> contributions then? Is there a standard procedure or policy for github vs.
> JIRA?
>
> Thanks in advance,
>
> Taylor
>

Re: Github Permissions for Committers

[P. Taylor Goetz]

Thanks for the clarification Jake.


> There is a very small number of people who have access to the Github Apache
> organization and they are the ones responsible for managing and maintaing
> the mirrors. It would be very difficult to deal with the auth on an
> external system and cross usernames which do not match up and maintaining
> each projects permissions not only internally but also externally. Also the
> audit trail for a pull request being granted use to the ASF is not straight
> forward

Should we discourage the use of github pull requests for code contributions 
then? Is there a standard procedure or policy for github vs. JIRA?

Thanks in advance,

Taylor


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Github Permissions for Committers

[Jake Farrell]

Comments inline, if you have any other questions or need any help let me
know

-Jake


On Fri, Dec 13, 2013 at 12:53 PM, P. Taylor Goetz  wrote:

> Is it possible for committers to get permissions to manage github issues
> (mainly ability to close them) for the github apache mirrors?
>

No, you can ask infra to help close all open issues. I would recommend that
you commented on them first asking that a patch or jira ticket be submitted
for it.


>
> The repo I’d like access to: https://github.com/apache/incubator-storm
> My github username: ptgoetz
>
>
There is a very small number of people who have access to the Github Apache
organization and they are the ones responsible for managing and maintaing
the mirrors. It would be very difficult to deal with the auth on an
external system and cross usernames which do not match up and maintaining
each projects permissions not only internally but also externally. Also the
audit trail for a pull request being granted use to the ASF is not straight
forward



> Also, I’ve heard that opening pull requests to apache/* repositories
> should trigger emails to the corresponding dev@ mailing list. But for
> storm I’m not seeing that happen.
>

> Is there anything I need to do to enable that?
>
>
You can ask infra to set this up for you.


> Thanks,
>
> Taylor
>

Github Permissions for Committers

[P. Taylor Goetz]

Is it possible for committers to get permissions to manage github issues 
(mainly ability to close them) for the github apache mirrors?

The repo I’d like access to: https://github.com/apache/incubator-storm
My github username: ptgoetz

Also, I’ve heard that opening pull requests to apache/* repositories should 
trigger emails to the corresponding dev@ mailing list. But for storm I’m not 
seeing that happen.

Is there anything I need to do to enable that?

Thanks,

Taylor


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Release Verification Checklist

[ant elder]

The N word wasn't particularly helpful or constructive, sorry. I do think
the policy page should be kept simple and generic though, so isn't the
place to be describing this experiment.

   ...ant


On Fri, Dec 13, 2013 at 3:39 PM, ant elder  wrote:

> Well sorry but IMHO thats nonsense. The Maven decision was an isolated
> incident and didn't change the way all future Incubator policy should
> get decided. Insisting that this experiment is done via a change to
> the main policy just makes it contentious when it doesn't need to be.
> All the complexity in the language and approach, the three votes etc
> is exactly why people get the idea that the ASF is a ridiculous place
> with overbearing rules and process. Its just an experiment, use lazy
> majority consensus and go try it with a podling.
>
>...ant
>
> On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey 
> wrote:
> > On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
> >> I'm also opposed to updating the policy document, so will be voting
> against
> >> this just for that.  Its just an experiment so you don't need to be
> making a
> >> permanent change to the policy page to try it, especially as its such a
> >> clunky convoluted change.
> >
> > An explicit policy change is required because otherwise there would be
> > ambiguity as to whether a release which passes under the modified regime
> is an
> > act of the Foundation and confers indemnity on the Release Manager.
> >
> > The language of the proposed change to the Policy page has been carefully
> > composed.  It is highly isolated from the rest of our policy and has no
> force
> > except on the the experiment.
> >
> > This proposal is structured as an incremental, reversible change.  It is
> > incremental because podlings must be opted in by vote of the IPMC to
> > participate.  It is reversible because once the experiment has run its
> course
> > the relevant section of the policy page can be removed with zero impact
> > through lazy consensus.
> >
> >> (And responding to another related comment in the thread - since when
> have
> >> policy updates not required consensus?)
> >
> > The 2008 proposal to allow distribution through Maven was enacted after a
> > contentious majority-rule vote passed 15 to 12.
> >
> > Marvin Humphrey
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: Release Verification Checklist

[ant elder]

Well sorry but IMHO thats nonsense. The Maven decision was an isolated
incident and didn't change the way all future Incubator policy should
get decided. Insisting that this experiment is done via a change to
the main policy just makes it contentious when it doesn't need to be.
All the complexity in the language and approach, the three votes etc
is exactly why people get the idea that the ASF is a ridiculous place
with overbearing rules and process. Its just an experiment, use lazy
majority consensus and go try it with a podling.

   ...ant

On Fri, Dec 13, 2013 at 3:27 PM, Marvin Humphrey  wrote:
> On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
>> I'm also opposed to updating the policy document, so will be voting against
>> this just for that.  Its just an experiment so you don't need to be making a
>> permanent change to the policy page to try it, especially as its such a
>> clunky convoluted change.
>
> An explicit policy change is required because otherwise there would be
> ambiguity as to whether a release which passes under the modified regime is an
> act of the Foundation and confers indemnity on the Release Manager.
>
> The language of the proposed change to the Policy page has been carefully
> composed.  It is highly isolated from the rest of our policy and has no force
> except on the the experiment.
>
> This proposal is structured as an incremental, reversible change.  It is
> incremental because podlings must be opted in by vote of the IPMC to
> participate.  It is reversible because once the experiment has run its course
> the relevant section of the policy page can be removed with zero impact
> through lazy consensus.
>
>> (And responding to another related comment in the thread - since when have
>> policy updates not required consensus?)
>
> The 2008 proposal to allow distribution through Maven was enacted after a
> contentious majority-rule vote passed 15 to 12.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Release Verification Checklist

[Marvin Humphrey]

On Fri, Dec 13, 2013 at 12:18 AM, ant elder  wrote:
> I'm also opposed to updating the policy document, so will be voting against
> this just for that.  Its just an experiment so you don't need to be making a
> permanent change to the policy page to try it, especially as its such a
> clunky convoluted change.

An explicit policy change is required because otherwise there would be
ambiguity as to whether a release which passes under the modified regime is an
act of the Foundation and confers indemnity on the Release Manager.

The language of the proposed change to the Policy page has been carefully
composed.  It is highly isolated from the rest of our policy and has no force
except on the the experiment.

This proposal is structured as an incremental, reversible change.  It is
incremental because podlings must be opted in by vote of the IPMC to
participate.  It is reversible because once the experiment has run its course
the relevant section of the policy page can be removed with zero impact
through lazy consensus.

> (And responding to another related comment in the thread - since when have
> policy updates not required consensus?)

The 2008 proposal to allow distribution through Maven was enacted after a
contentious majority-rule vote passed 15 to 12.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [ANNOUNCE] Billie Rinaldi joins the IPMC

[larry mccay]

Congrats, Billie!


On Thu, Dec 12, 2013 at 3:34 PM, Marvin Humphrey wrote:

> Apache Member Billie Rinaldi, the PMC Chair for Accumulo and a member of
> the
> Ambari PMC, has elected to join the Incubator PMC.
>
> May you have as much success as an IPMC member as you had as a PPMC member
> of
> the Accumulo podling!
>
> Marvin Humphrey, on behalf of the Incubator PMC
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Release Verification Checklist

[ant elder]

On Fri, Dec 13, 2013 at 7:54 AM, Marvin Humphrey wrote:

> On Thu, Dec 12, 2013 at 8:56 PM, Dave Fisher 
> wrote:
>



> So...
>
> *   Ant likes the voting rule change, but is opposed to the checklist.
>

I'm also opposed to updating the policy document, so will be voting against
this just for that. Its just an experiment so you don't need to be making a
permanent change to the policy page to try it, especially as its such a
clunky convoluted change.

(And responding to another related comment in the thread - since when have
policy updates not required consensus?)

   ...ant