Hi,
Been following the thread and noticed one of the items on the list is:
"Issue tracker clean for release version."
Is that really expected? I would expect progress and issue closed since
last release but not everything in the issue tracker addressed. Is it clear
what "clean" means in this context?
Committers work and fix what they want ("scratch your own itch"), some
issues may take a while to get fixed (span releases) and some may never get
fixed. A project coming into Apache may also have a number of existing
issues and fixing them all may not even be possible in a reasonable amount
of time.
Thanks,
Justin
On Mon, Dec 9, 2013 at 3:49 PM, 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
>
>
