Re: 8.5 release timetable, again

On Thu, Aug 27, 2009 at 6:09 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> The final CommitFest began November 11, 2008.  It closed March 25,
>>> 2009 (+ 144 days).  Beta1 was released April 15, 2009 (+ 21 days).
>
>> I'm not entirely clear on what was happening during the 21 days
>> between the end of the CommitFest and and the release of beta1.
>
> Release note drafting is one part of it, but mostly it's "loose end
> cleanup".  Historically there have always been a pile of loose ends
> to be dealt with, and the CommitFest structure doesn't really do
> anything to avoid that.  If you're interested, attached are all the
> commits between commitfest closure (which I announced immediately
> after committing the addition of contrib/btree_gin) and stamping
> beta1 (which was actually several days before the date Robert gives,
> because of the need for the packagers to do their thing).
>
> It appears to me that release notes weren't actually the bottleneck this
> time, though they have been in some prior cycles.  Bruce committed a
> first draft immediately after the commitfest closed.  Rather, it was
> arguing about things like \df behavior and cardinality() that took up
> the time.

It felt, at the time, like the release notes were holding things up,
hence the various and so-far-unsuccesful volunteering related to that
task. But it's possible that there was enough parallel activity going
on that it wasn't actually so.

> We could certainly have released a perhaps-less-polished beta earlier.
> I think that the traditional criterion is that we don't release beta1
> as long as there are any known issues that might force an initdb.
> We were successful in avoiding a post-beta initdb this time, although
> IIRC the majority of release cycles have had one --- so maybe you
> could argue that that's not so important.  It would certainly be
> less important if we had working pg_migrator functionality to ease
> the pain of going from beta to final.
>
> Now that we have the alpha-release mechanism defined, some of the
> pressure for a quick beta could be taken off by releasing a final
> alpha right after the final commitfest closes.

Definitely. Looking at it in hindsight, 3 weeks seems like a
reasonable amount of time between the end of the last CommitFest and
the start of beta. It felt long at the time, but maybe that's partly
because the CommitFest was so intermininable.

I think what a lot of this boils down to is that we need a better
system for managing the tasks that need to be completed at each stage
of the release process, and who is working on each one, and what the
status of it is, just as we do for CommitFests.

...Robert