On Sat, Mar 26, 2011 at 11:46 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Greg Stark <gsst...@mit.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
