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/". -David > 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. > > http://incubator.apache.org/guides/release.html > https://wiki.apache.org/incubator/ReleaseChecklist > > 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: <http://markmail.org/message/2ncepopzgnshtyd6>. > > * Build instructions are provided, unless obvious > > I haven't found any documentation that this is required anywhere on > www.apache.org/dev or www.apache.org/legal. 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: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
