Re: damage control mode

On Mon, Jan 11, 2010 at 8:14 PM, David Fetter <david(at)fetter(dot)org> wrote:
> On Mon, Jan 11, 2010 at 07:50:23PM -0500, Bruce Momjian wrote:
>> Josh Berkus wrote:
>> > I'll also say: if we can't make time-based releases work, we're
>> > probably dead as a project.  MySQL and Ingres both tried
>> > feature-based releases, and look where they are now.
>>
>> That is a simplification.  We have always done time-based releases
>> with adjustments for feature/stability.  If we can't factor
>> stability concerns into the release timetable, we will end up like
>> MySQL.
>
> Comparisons to MySQL or other proprietary software just aren't
> pertinent to this discussion.
>
> If we're looking to other projects, the Linux kernel might be more
> relevant.  That has, for the nonce, decided to sacrifice stability for
> time-based releases.  People who help package the kernel for
> distributions are better qualified than I to discuss the merits of
> this approach.

The decision as to whether to have time-based releases or
feature-based releases is a separate issue from the decision about
whether to have well-tested, thought-to-be-bug free releases or
slapped-together, crufty releases. I suspect I speak for everyone
here when I say that the stability of our releases is a point of pride
for the project and that we would never consider sacrificing it.

The difference between a time-based release and a feature-based
release is that a time-based release is planned to occur at a certain
time. A feature-based release is planned to occur when certain
features are completed. Of course, the disadvantage of time-based
releases is that you can never be sure exactly what they will contain
until you get to the end of the development cycle and see what got
done. With a feature-based release, you can have more confidence that
the features you were expecting will be in the next release, but you
might have to wait a very long time for that release to actually
happen. For a project like PostgreSQL, which has none of its own
staff and where anyone can change their mind not only about the timing
of a particular patch but also about doing it at all, you might be
waiting a very long time indeed.

Time-based releases do present a certain challenge in terms of release
management. If we target a release for June, and we really want to
have that release happen in June, then we have to back up from June
and think about where we need to be in, say, January. If we find
ourselves behind, we have to be willing to throw over some features to
make our scheduled time. Of course, this is not an exact science, but
you estimate what you need to do and take your best shot. Enforcing
rules like "no large, new patches in the final CommitFest" can help us
make reasonable decisions about which things should be postponed.

The consensus view on this thread seems to be that we should have a
time-based code freeze, but not a time-based release. No one has
argued (and I sincerely hope no one will argue) that we should let the
last CommitFest drag on and on, as we did for 8.4. However, many
people are still eager to see us commit more large patches even though
they know that there are stop-ship issues in CVS HEAD as a result of
Hot Standby, and despite the fact that committing more large patches
will likely add more such issues. So, barring the possibility that we
somehow pull a collective rabbit out of our hat, we will NOT be ready
for beta on March 1. I have not yet given up hope on April 1, but I
wouldn't bet on it, either.

As someone pointed out upthread, even if the only thing we do
differently relative to 8.4 is end the last CommitFest on time (i.e.
time-based code freeze), that's an improvement. However, my
frustration with 8.4 was not only that the last CommitFest was very
long, but also that it took quite a long time after the last
CommitFest was concluded to get the release out the door. The result
was that the tree was closed to new patches for a very long time (8
months). I would like to see us shorten that interval this time
around, and I would like to see us be more aggressive in trying to do
so. I think the theory that CommitFests and/or alpha releases and/or
pg_migrator are going to speed up the final release over previous
cycles is, unfortunately, wishful thinking: I strongly suspect that
the limiting factor is going to be how quickly can we can get to beta.

Upthread, Peter asked what it means to get to beta. Someone with more
seniority on the project than me will certainly make the decision on
when beta actually happens, but as I'm using it here, I mean that any
open issues that require significant code changes and/or catversion
bumps will have been addressed. We should not be aware of any open
issues that require fixes we wouldn't be willing to back-patch if they
were first found after release. That is the milestone which I do not
believe we are currently on track to meet in a timely fashion.

...Robert