PG 9.0 release timetable

On Sat, May 29, 2010 at 4:19 PM, Bruce Momjian <bruce@momjian.us> wrote:

Assuming we want a release Postgres 9.0 by mid-August, here is how the
timetable would look:

       Need RC release to be stable for 1-2 weeks before final
               RC must be released by August 1
       Beta must be stable for 2-3 weeks before RC
               Stable beta must be released by early July

So, we have 5-6 weeks to get a stable beta.  Looking at the open issues:

       http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Resolved_Issues

it looks like we are doing OK, but we must continue progressing.

This is a really short list. Several of these items have already been
fixed, and others have been discussed extensively and are just a
question of making a final decision. The thorniest question we have
yet to resolve is what to do about max_standby_delay - I think we need
Tom and Heikki to review this patch by Simon:
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01666.php

The real question in terms of release, I think, is how long we want to
wait for more bugs to be found, and/or how much time do we want to
allow for Tom and others to do further review of the code.

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

On Sat, May 29, 2010 at 5:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:

This is a really short list.

Thoughts on a few of the remaining items:

Type Mismatch Error in Set Returning Functions - tgl says this is a
deliberate change per link I just added to the wiki. do we think more
is required here to prevent cranky users?
Should we revert the default output format for bytea to the old style
before shipping 9.0.0? - Consensus seems to be "no", thus no action is
required.
don't rename index columns behavior has already broken JDBC - As I
understand it, this is not a code issue, but just something that
driver authors need to be aware of.
Crash in buildfarm for Mac OS X 10.6.3 - Consensus seems to be that
the machine just ran out of disk space - not sure we need to do
anything here.
move 'long long' check to c.h - Is this perhaps addressed by Michael
Meskes commits on May 25th?
Mergejoin null handling - I think this is done:
http://archives.postgresql.org/pgsql-committers/2010-05/msg00332.php
Timeline for removal of older than 7.4 links to docs - link on the
wiki page is broken and this doesn't seem like a 9.0 issue anyway.
suggest we remove it.

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

Robert Haas <robertmhaas@gmail.com> writes:

Thoughts on a few of the remaining items:

Should we revert the default output format for bytea to the old style
before shipping 9.0.0? - Consensus seems to be "no", thus no action is
required.

I think we should leave that there for awhile, though I agree it's
likely that the final decision will be "no change".

don't rename index columns behavior has already broken JDBC - As I
understand it, this is not a code issue, but just something that
driver authors need to be aware of.

There had been a section on the page about information we needed to
communicate to third-party authors. Someone seems to have removed
that, but that seems like where this belongs.

Crash in buildfarm for Mac OS X 10.6.3 - Consensus seems to be that
the machine just ran out of disk space - not sure we need to do
anything here.

It's a bit weird though, because UpdateControlFile should always update
in place; why would there be any risk of out of disk space? I would
like to find out exactly what happened, though I have no clear ideas
how to investigate it.

move 'long long' check to c.h - Is this perhaps addressed by Michael
Meskes commits on May 25th?
Mergejoin null handling - I think this is done:

Yup, both done, I moved them.

regards, tom lane

On Sat, May 29, 2010 at 5:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Thoughts on a few of the remaining items:

Should we revert the default output format for bytea to the old style
before shipping 9.0.0? - Consensus seems to be "no", thus no action is
required.

I think we should leave that there for awhile, though I agree it's
likely that the final decision will be "no change".

don't rename index columns behavior has already broken JDBC - As I
understand it, this is not a code issue, but just something that
driver authors need to be aware of.

There had been a section on the page about information we needed to
communicate to third-party authors.  Someone seems to have removed
that, but that seems like where this belongs.

Crash in buildfarm for Mac OS X 10.6.3 - Consensus seems to be that
the machine just ran out of disk space - not sure we need to do
anything here.

It's a bit weird though, because UpdateControlFile should always update
in place; why would there be any risk of out of disk space?  I would
like to find out exactly what happened, though I have no clear ideas
how to investigate it.

Well, I think at a minimum the first two of these need to go into a
section that is not called "code": the first is just a decision we
might change our mind about, and the second is a communication issue,
not a code issue. I'd argue that the third one is probably not
something we're going to hold up the release for, either, and
therefore while it might belong on a list of known open bugs it
doesn't really belong on a list of 9.0 open items.

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

On Sat, 2010-05-29 at 16:19 -0400, Bruce Momjian wrote:

Assuming we want a release Postgres 9.0 by mid-August, here is how the
timetable would look:

Need RC release to be stable for 1-2 weeks before final
RC must be released by August 1
Beta must be stable for 2-3 weeks before RC
Stable beta must be released by early July

So, we have 5-6 weeks to get a stable beta. Looking at the open issues:

http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Resolved_Issues

it looks like we are doing OK, but we must continue progressing.

We've fixed most of the beta1 issues some time ago and beta testers are
waiting for next beta before doing further testing, so absence of new
bugs means very little.

We're currently at 4 weeks since last beta, with no new beta in sight.
If we want to stick to the timetable we should be releasing new beta
releases every 2-3 weeks, not every 4-5 weeks. Our objective (or
realisation of necessity) should be 4-5 betas each release.

Waiting for "stable" just introduces delay during beta, though makes
sense for RC. Delay means hackers take their eyes off the release and do
other things, which further slows down the release. Let's accept that
its OK to release another beta while the open items list isn't empty and
reap the next crop of bugs from betas.

If we're going enforce code windows we should be enforcing things
throughout the whole release cycle. We must keep a sensible pace if we
want to keep people involved in the process.

--
Simon Riggs www.2ndQuadrant.com

On 31 May 2010 09:33, Simon Riggs <simon@2ndquadrant.com> wrote:

We're currently at 4 weeks since last beta, with no new beta in sight.

My understanding was beta 2 would be out on 7th June. Is that changing?

Thom

On Mon, 31 May 2010, Thom Brown wrote:

On 31 May 2010 09:33, Simon Riggs <simon@2ndquadrant.com> wrote:

We're currently at 4 weeks since last beta, with no new beta in sight.

My understanding was beta 2 would be out on 7th June. Is that changing?

Yes, but Simon is correct in that 4-5 weeks between betas is a long time,
when most bugs will be reported (and hopefully fixed) relatively quickly
after a beta is released ... RC should be held to a more 'release
standard', but beta's should be closer to a snapshot standard, with a more
short/fixed timeframe so that debuggers aren't hitting the same bugs that
were reported (and fixed), weeks earlier ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy@hub.org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org

On Mon, May 31, 2010 at 2:22 PM, Thom Brown <thombrown@gmail.com> wrote:

On 31 May 2010 09:33, Simon Riggs <simon@2ndquadrant.com> wrote:

We're currently at 4 weeks since last beta, with no new beta in sight.

My understanding was beta 2 would be out on 7th June.  Is that changing?

No. It's very much in sight on my calendar :-)

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

On Mon, 2010-05-31 at 15:14 +0100, Dave Page wrote:

On Mon, May 31, 2010 at 2:22 PM, Thom Brown <thombrown@gmail.com> wrote:

On 31 May 2010 09:33, Simon Riggs <simon@2ndquadrant.com> wrote:

We're currently at 4 weeks since last beta, with no new beta in sight.

My understanding was beta 2 would be out on 7th June. Is that changing?

No. It's very much in sight on my calendar :-)

Can we make it 2 weeks per beta from now on?

That will allow us to get to Beta5 by 19 Jul, which will hopefully
become RC1 on 2 Aug and then release on 16 Aug.

At the current pace we will be on BETA3 on 12 July, increasing the
probablity of delay, or reducing the number of bugs discovered prior to
release.

If that's a problem, do we need to release BetaN on all platforms? Where
do the majority of bug reports originate? Let's focus there.

--
Simon Riggs www.2ndQuadrant.com

"Marc G. Fournier" <scrappy@hub.org> writes:

On Mon, 31 May 2010, Thom Brown wrote:

On 31 May 2010 09:33, Simon Riggs <simon@2ndquadrant.com> wrote:

We're currently at 4 weeks since last beta, with no new beta in sight.

My understanding was beta 2 would be out on 7th June. Is that changing?

Yes, but Simon is correct in that 4-5 weeks between betas is a long time,

The reason it went like that is that (a) we had PGCon in there, and (b)
we had a set of security releases in there. Asking for another beta
to have happened is pointless. You might recall that I already *did*
ask that --- I wanted beta2 to happen concurrently with the security
releases --- and was turned down.

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

regards, tom lane

Simon Riggs <simon@2ndQuadrant.com> writes:

We're currently at 4 weeks since last beta, with no new beta in sight.

Eh?
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01649.php
You can hardly claim to have not seen it.

regards, tom lane

On Mon, 31 May 2010, Tom Lane wrote:

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

How many beta testers out there *rely* on a package to do their testing?
I'm not saying don't try and get packages in place, I'm just saying it
shouldn't be a requirement to stamp code BETA and create a tar ball ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy@hub.org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org

Marc G. Fournier wrote:

On Mon, 31 May 2010, Tom Lane wrote:

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

How many beta testers out there *rely* on a package to do their testing?
I'm not saying don't try and get packages in place, I'm just saying it
shouldn't be a requirement to stamp code BETA and create a tar ball ...

Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

On Mon, May 31, 2010 at 5:30 PM, Bruce Momjian <bruce@momjian.us> wrote:

Marc G. Fournier wrote:

On Mon, 31 May 2010, Tom Lane wrote:

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

How many beta testers out there *rely* on a package to do their testing?
I'm not saying don't try and get packages in place, I'm just saying it
shouldn't be a requirement to stamp code BETA and create a tar ball ...

My guess would be "most of them".

Unlike alphas where most probably just work off a tree - or so it seems.

That's obviously going to be very platform dependent.

Well, they can just grab nightly snapshots and test, right?  I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

Source-code wise, no, it's not - except that it's a well defined point
in time, so it's easier to report bugs against, and to search for
known bugs against.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Mon, 31 May 2010, Bruce Momjian wrote:

Marc G. Fournier wrote:

On Mon, 31 May 2010, Tom Lane wrote:

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

How many beta testers out there *rely* on a package to do their testing?
I'm not saying don't try and get packages in place, I'm just saying it
shouldn't be a requirement to stamp code BETA and create a tar ball ...

Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

doesn't really give a good reference point for testing purposes ... if
everyone downloads BETA2 and tests, they are all testing the exact same
code ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy@hub.org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org

On Mon, 31 May 2010, Magnus Hagander wrote:

My guess would be "most of them".

Do we not have any stats on # of beta downloads per package type? I use
FreeBSD ports when installing production, but when testing non-released
code, I generally use the source code itself and build ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy@hub.org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org

"Marc G. Fournier" <scrappy@hub.org> writes:

On Mon, 31 May 2010, Bruce Momjian wrote:

Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

doesn't really give a good reference point for testing purposes ...

It's also inferior from a documentation standpoint --- we don't update
the release notes nightly.

regards, tom lane

On Mon, May 31, 2010 at 5:35 PM, Marc G. Fournier <scrappy@hub.org> wrote:

On Mon, 31 May 2010, Magnus Hagander wrote:

My guess would be "most of them".

Do we not have any stats on # of beta downloads per package type?  I use FreeBSD ports when installing production, but when testing non-released code, I generally use the source code itself and build ...

No. Most packages don't come off the postgresql.org servers - they
come out of the yum repositories, the deb repositories or the edb
download servers (windows).

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Mon, 31 May 2010, Tom Lane wrote:

"Marc G. Fournier" <scrappy@hub.org> writes:

On Mon, 31 May 2010, Bruce Momjian wrote:

Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

doesn't really give a good reference point for testing purposes ...

It's also inferior from a documentation standpoint --- we don't update
the release notes nightly.

There are three things that *have* to be involved in doing a Beta:

translation updated
release notes
tar ball

There doesn't need to be any web site announce or anything, only a note
out to -hackers that we have a new beta ready for testing ...

If we were to do that every 2 weeks, on a Friday, then any packagers that
are able to can get their package ready and up for testing ... but, for
those that are able to build from sources (I would hope any/everyone on
-hackers can handle that?), they would have a firm release to build / run
tests on that includes all bugs fixed in the previous 2 weeks ...

----
Marc G. Fournier Hub.Org Hosting Solutions S.A.
scrappy@hub.org http://www.hub.org

Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org

"Marc G. Fournier" <scrappy@hub.org> writes:

On Mon, 31 May 2010, Tom Lane wrote:

I find myself entirely unimpressed by proposals to make releases
according to some rigid schedule that takes no account of whether
packaging manpower is actually available.

How many beta testers out there *rely* on a package to do their testing?

A lot of them --- probably approximately 100% of the Windows population,
for example. People who are capable of working from source are likely
not waiting for beta packages anyway, just using CVS or nightly
snapshots.

I'm not saying don't try and get packages in place, I'm just saying it
shouldn't be a requirement to stamp code BETA and create a tar ball ...

There's more work that goes into a beta release than just stamping,
as you should know as well as anyone. Otherwise we might as well call
the nightly snapshots beta releases.

regards, tom lane

On Mon, 2010-05-31 at 11:10 -0400, Tom Lane wrote:

Simon Riggs <simon@2ndQuadrant.com> writes:

We're currently at 4 weeks since last beta, with no new beta in sight.

Eh?
http://archives.postgresql.org/pgsql-hackers/2010-05/msg01649.php
You can hardly claim to have not seen it.

Yes, completely wrong. A sunny weekend away wiped my mind. Hopefully
that doesn't detract from the other points I made.

--
Simon Riggs www.2ndQuadrant.com

On Mon, 2010-05-31 at 11:30 -0400, Bruce Momjian wrote:

Well, they can just grab nightly snapshots and test, right? I don't
think a beta is fundamentally different from a nightly snapshot,
source-code wise.

There is only one difference: the signal to re-test.

Most people read "new beta" as meaning "we fixed the bugs, try again
now". The delivery mechanism is unimportant.

IMHO the amount of testing we get is directly proportional to number of
announced beta releases, since most tests get run in first week.

If packaging is the issue, lets announce packaged releases every 4 weeks
and non-packaged snapshots every 2 weeks.

--
Simon Riggs www.2ndQuadrant.com