Re: Duration of beta period - Mailing list pgsql-hackers

My two cents:

We do need to make the beta period shorter and more focused; and it's
core's responsibility to make that happen by setting the project timeline.

Last fall we had some people still working on new features months after
others had gone into time-for-beta, no-new-features hibernation.  That's
not good; it wastes potential development time to no purpose.  And it's
core's fault for not setting clear expectations for the group (the fact
that there were core members in each camp didn't help un-confuse anyone,
either).  Once we did enter beta, it seemed curiously slow and
unfocused, at least to me.  I think that we got less beta testing than
we have in past cycles, not more --- for example, our failure to learn
that pg_dump was broken for mixed-case database or user names doesn't
speak well to the number of active databases that were migrated.
I suspect that the apparent high quality of the 7.2 release is a matter
of luck, and not a sign of good project management at all.

I believe that both Marc and Bruce have good points here.  As Marc says,
the ultimate bottom line must always be "it's ready when it's ready";
we cannot allow a schedule target to push us into making bad decisions.
But I think Bruce is also correct that we need to have *some* schedule
target, just so that developers can make plans about what features to
work on or leave for a future cycle.  And we need to be more willing
to tell people "you missed the bus for this release"; slipping a
previously-agreed-to release date because noncritical features are still
being worked on is bad project management IMHO.  (BTW, getting back to
a more frequent release cycle would help to make that a more palatable
decision.  If it's four months to the next release, people will be more
willing to wait than if they fear it'll be a year or more.)

As for improving the amount of testing that gets done, maybe we could
advertise the availability of beta releases more widely --- notify
freshmeat, slashdot, etc.

Peter Eisentraut <peter_e@gmx.net> writes:
> My feeling during this beta was that a lot of the bugs, porting problems,
> etc. could have been caught earlier, that is, before beta, if we had
> encouraged more people to run the early snapshots.  In the past, we've
> effectively told people, "You're insane if you use development snapshots"
> and we've really not revealed at all what the new release was going to be
> about until briefly after the start of beta.

True, but we can only improve that if we devote some nontrivial effort
to creating reasonably-trustworthy snapshots.  Right now, no one blinks
an eye if the overnight snapshot is nonfunctional; we fix the problem
and move on.  But how is someone who's not well-tuned-in to know which
nightly snapshots might be safe to use for their own development work?

I think we'd have to make mini-releases, more or less, to attract
testers to use between-releases snapshots.  Maybe that's actually a good
idea, but how will we avoid spending lots of development effort to
coordinate them?
        regards, tom lane