I know you're passionate about this Marvin but as it stands I'll be voting against this proposal.
1) This proposal doesn't help podlings with the first release 2) Podlings should normally graduate after the first release (and we should more proactively do that) not stay to do more 3) The proposal adds new artificial process around doing a release when we should be teaching podlings how TLPs do things IMHO the Incubator has lost the plot with this focus on release artifacts, we should instead focus on teaching podlings about how to build strong communities around their project. It is not the primary objective for the Incubator to protect the ASF from a rogue podling release. Many many releases have been done in the ASF that have gone out with problems but I have never heard of the ASF getting in to any trouble from them, ever. Where as, many Incubator podlings and the public perception of the ASF have been damaged by the problems around doing an Incubator release. Incubator releases are not official ASF releases so there is not and should not be the same expectations around them. If we could find a way to have Incubator PMC members accept a lower bar for doing podling releases it would make a massive improvement to everyones experience of the Incubator. ...ant On Mon, Dec 9, 2013 at 4:49 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Fri, Dec 6, 2013 at 1:55 AM, ant elder <ant.el...@gmail.com> 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. > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
