On Sat, Mar 26, 2011 at 3:46 PM, 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
> * 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
> * No known data-loss-causing bugs (duh)
> Comments? Any other quality criteria we should have for beta?
Last 2 are pretty clear.
The first one is debatable because of the word "expected". Who decides that?
I want more feedback into the project. That can obviously result in
changes that are user visible. Users don't complain about non-user
I'd state it the other way around: No open issues that are expected to
result in non-user visible architecture changes.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-03-26 16:39:24|
|Subject: Re: race condition in sync rep|
|Previous:||From: Greg Stark||Date: 2011-03-26 16:34:55|
|Subject: Re: Open issues for collations|