Re: 8.5 release timetable, again

On Sun, Aug 23, 2009 at 1:57 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I posted a note about a week ago which drew far less commentary than I
>> expected, regarding the timetable for the release of 8.5.
>
>> http://archives.postgresql.org/pgsql-hackers/2009-08/msg01256.php
>
>> Perhaps this is already being discussed on -core, but if so the
>> conclusions haven't been shared publicly.
>
> Core hasn't discussed 8.5 schedule since the discussions that Peter
> summarized in the message you cited above.  I share your concern that
> "release in time for PGCon" isn't very realistic if we don't get more
> aggressive about schedule.  On the other hand, we didn't get all that
> much done in this fest.  If we cut back to a three-fest schedule
> I think we may succeed in releasing 8.5 early, but only because there
> is nothing interesting in it :-(.  Dunno where the right balance is.

Here is my thinking on that point. We have several major features
underway for the September CommitFest, including at least Hot Standby
(Simon Riggs), Streaming Replication (Fujii Masao), and Index-Only
Scans (Heikki). At the July CommitFest, none of these patches were in
a state where they could be seriously reviewed. Simon Riggs and Fujii
Masao have both committed to produce reviewable versions by 9/15, and
it looks like Heikki will hit that date too, if not beat it.

I am assuming that at least Hot Standby and Streaming Replication will
likely require two CommitFests to go from the point where they are
seriously reviewable to actual commit. So if they hit the 9/15 date,
they should make 8.5 even with just three CommitFests. If they don't
hit the 9/15 date, then a 3-CommitFest cycle will probably be too
short for them to make it in. But if we schedule a fourth CommitFest
in January in the hopes of seeing one of those patches committed, then
ISTM we're basically speculating that the patch authors will not hit
the 9/15 date but that they will hit an 11/15 date.

To me, that's an entirely arbitrary and unfounded speculation. On the
one hand, both patch authors have said they will hit 9/15, so why
should we second-guess them? On the other hand, neither of those
patches seems to have made a great deal of progress in the last 7
months, so it's unclear that tacking a few more months onto the
schedule will help anything. Furthermore, even if we're right that
four CommitFests is the right number to land one of those patches
(rather than 3 or 5 or 6 or 7), we're then talking about committing a
major feature in the very last CommitFest for this release. We tried
that for 8.4 and it wasn't a stunning success.

To some degree, what this boils down to is that you can have
time-based releases or feature-based releases, but not both. And the
problem with feature-based releases in a community environment is that
there is no guarantee that patches will be delivered when promised.
None of the people developing these major features work for the
community and we do not have the ability to control any of their
schedules. So saying that we're going to wait for them to be ready is
potentially saying that we're going to wait forever. No one is
proposing that, but we are sort of trying to read the tea leaves and
try to guess when they might be ready and tailor the schedule to it.

To me, it seems to make more sense to just decide we're going to ship
the release on a time line that works for the project overall. If we
get some new features in, good. If they slip a bit past the deadline,
well, at least that should hopefully mean that they get committed
right at the beginning of the 8.6 cycle. If they slip WAY past the
deadline, bummer, but at least we didn't hold up the release to no
benefit. I don't think there's anything wrong with having a release
that has many small improvements but no major new features, and I
think that is the worst that will happen.

...Robert