Skip site navigation (1) Skip section navigation (2)

Re: 9.1 Beta

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 9.1 Beta
Date: 2011-03-26 16:38:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
> 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?

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
visible things.

I'd state it the other way around: No open issues that are expected to
result in non-user visible architecture changes.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-03-26 16:39:24
Subject: Re: race condition in sync rep
Previous:From: Greg StarkDate: 2011-03-26 16:34:55
Subject: Re: Open issues for collations

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group