Re: 9.1 Beta

On Sat, Mar 26, 2011 at 11:46 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
>> There's not much point in releasing a beta with behaviour that we know
>> we intend to change. All it will do is elicit bug reports that we have
>> to respond to saying "we know, we were going to change that anyways".
>
>> I think the goal of a beta is to be able to say "we think this is the
>> final behaviour of the next release but we're open to feedback".
>
> Yeah, I think this is a productive way to approach the question.
> I would put on a couple of extra conditions, though.  Something like
> this:
>
> * No open issues that are expected to result in user-visible
> behavior changes.  (Or at least "significant" changes?  But then
> we have to argue about what's significant --- for instance, are
> the questions in the nearby collations-issues thread significant
> enough to be beta blockers?)
>
> * No open issues that are expected to result in a catversion bump.
> (With pg_upgrade, this is not as critical as it used to be, but
> I still think catalog stability is a good indicator of a release's
> maturity)
>
> * No known data-loss-causing bugs (duh)
>
> Comments?  Any other quality criteria we should have for beta?

I think all of these things are pretty subjective, but I broadly agree
with the way you've set it out here. Simon is right that it's
sometimes reasonable to ship the code as it is and see what feedback
we get. But there's a countervailing effect, too: once we ship the
code, then people get used to the way it works, and people don't want
to change it, even if it's not what they would have picked initially.
Magnus mentioned that he was going to upgrade some machine somewhere
to alpha5 once it was out. When my jaw fell off he assured me it
wasn't a critical system, but still: some people upgrade very early,
and once we declare beta, they're going to expect that we aren't going
to change too much. And even if they had no such expectation, we
don't WANT to change too much, because then we've got to allow more
time for beta-testing of the new stuff. It's much easier and much
less work to get it right the first time.

All that having been said, I think this whole thing may be a tempest
in a teapot. Regardless of what the exact criteria are for beta, I
think we're getting reasonably close to meeting them. Shaking out the
bugs in the collation stuff has taken longer than you originally
predicted, but it seems like we're homing in on it; and sync rep has
gone from a long list of open items (most of which were reported by
Fujii Masao, whose efforts I at least very much appreciate) to a much
shorter one. A couple of the other issues are in fact longstanding
bugs rather than new regressions in 9.1, and therefore can't be viewed
as beta blockers. I see no reason we can't finish the remaining items
in the next couple of weeks, barring a sudden influx of new bug
reports - especially if a few more people pitch in and help move
things forward.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company