incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: Release Verification Checklist
Date Fri, 20 Dec 2013 02:48:14 GMT
On Thu, Dec 19, 2013 at 5:07 PM, David Crossley <> wrote:
> There was a time not long ago, where hardly anything
> was documented. Rather it was just common-sense.
> So in my opinion, not being in those docs does not mean
> that it is not required.

If there are required items which have been inadvertently left off, we can add
them later.  We are already set to track optional items on the
ReleaseChecklist wiki page as well.

There should be a low threshold for adding an optional item to the wiki, and a
high threshold for adding a required item to the default checklist.  I have
added the following text to the Experimental Release Guide to clarify:

    Each review item in the default Manifest is either required by
    Foundation-wide policy and would block a release by any Apache top-level
    project, or is required by Incubator policy.

I can think of one item which was left off and should probably added to the
default checklist in my opinion:

    1.2 RM release signing key present in KEYS file.

> Votes should also encourage "anyone" to vote (though of course
> as non-binding). With this SVN based technique, how do they do that?

The PPMC VOTE must be called on the podling dev list.  Non-binding votes may
be cast as they are now -- via email -- and I agree that they should be

> If the dev list PPMC vote passes including 3+ IPMC members
> then there is no need for this "second vote".

Current Incubator policy requires the second vote on general@incubator.

    If the majority of all 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.

The experiment maintains this procedure.

> Also some good stuff is in the old "guides/releasemanagement.html"
> so we do need to ensure that is over at "a.o/dev/".

The experimental release guide supplants the old one as a spec, but not as an
archive of opinions about best practices.  A single document cannot serve well
in both capacities.  We need both, and they must be separate.

Marvin Humphrey

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message