Thread: PG 9.0 release timetable
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 1Beta must be stable for 2-3 weeksbefore 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com
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, 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, butwhen 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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.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 HaganderMe: 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