PG 9.0 release timetable
in [PgSql]
|
Prev: [HACKERS] PG 9.0 release timetable
Next: : CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up
From: Robert Haas on 29 May 2010 17:09 On Sat, May 29, 2010 at 4:19 PM, Bruce Momjian <bruce(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 May 2010 17:37 On Sat, May 29, 2010 at 5:09 PM, Robert Haas <robertmhaas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 May 2010 17:58 Robert Haas <robertmhaas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 May 2010 23:12 On Sat, May 29, 2010 at 5:58 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 31 May 2010 04:33 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [HACKERS] PG 9.0 release timetable Next: : CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up |