incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Release Verification Checklist
Date Fri, 20 Dec 2013 01:07:00 GMT
Marvin Humphrey wrote:
> ant elder wrote:
> >
> > All the stuff required to be checked when voting on a release should be
> > documented in the ASF doc about releases. That its not in that doc suggests
> > its not required. If someone thinks something is required then they should
> > go get consensus around that with the wider ASF and get the ASF doc updated.

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.

(Not sure where to insert some other comments in this thread,
so will just dump them here.)

I am concerned about potentially changing the way we do things.
So, two comments with that in mind:

Votes should also encourage "anyone" to vote (though of course
as non-binding). With this SVN based technique, how do they do that?
The current new "guides/release.html" says "contains a link URL
for the Manifest". I suppose that they could be encouraged to
copy the text from SVN and reply via the dev mail list.

If the dev list PPMC vote passes including 3+ IPMC members
then there is no need for this "second vote".
The wording gives a slight twist which might sway the
understanding of why we do such things.

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


> OK, I've done the research and I've migrated the manifest proposal to a new
> documentation page with the links.  The ReleaseChecklist wiki page is now a
> home for optional checklist items.
> Applying your criteria to the current checklist has resulted in the
> migration of two items to the optional list:
> *   Each expanded source archive matches the corresponding SCM tag.
>     It turns out the only place matching the SCM tag was documented is the
>     Incubator's Release Management guide.  Here's Leo Simons making the case
>     against: <>.
> *   Build instructions are provided, unless obvious
>     I haven't found any documentation that this is required anywhere on
> or  Bertrand, between me arguing
>     that this won't come into play often enough and Ant and Olivier arguing
>     that we should only include blockers documented elsewhere, I've made the
>     judgment call that this should be moved to the optional list as well.
>     Please let us know if you object.
> > Podling releases are not quite the same as TLP releases, thats why they
> > have the DISCLAIMER and "incubating" naming. I think we should be making it
> > easier for podlings to do releases, if its really necessary then make an
> > audit of the last release a requirement of graduation.
> I am passionately committed to making it easier for podlings to release, by
> granting limited self-governance to those who earn it.
> The proposal under consideration is a win for *both* streamlining the release
> voting process and improving release oversight.
> Marvin Humphrey

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

View raw message