9.2 release schedule

On 21 July 2012 08:08, Bruce Momjian <bruce@momjian.us> wrote:

What are our plans for a 9.2 final release date? If we wait until
September 1 to release our first release candidate, we will probably not
release final until mid/late September. Is that what we want?

Personally I had hoped to see an earlier release date than that.

Can we finish the 9.2 release notes?

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Peter Geoghegan <peter@2ndquadrant.com> writes:

On 21 July 2012 08:08, Bruce Momjian <bruce@momjian.us> wrote:

What are our plans for a 9.2 final release date? If we wait until
September 1 to release our first release candidate, we will probably not
release final until mid/late September. Is that what we want?

Personally I had hoped to see an earlier release date than that.

Me too, but we are running out of time ... it's already late July.

I think the immediate goal must be to clear the list of open issues
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
and then get another beta out.

It seems unlikely that we could do a beta next week (for one thing,
certain key people are going to be out sailing...) but maybe we could
schedule the next beta for first Monday in August? That gives us
about ten days to get the open issues dealt with before wrapping.

regards, tom lane

I wrote:

Peter Geoghegan <peter@2ndquadrant.com> writes:

On 21 July 2012 08:08, Bruce Momjian <bruce@momjian.us> wrote:

What are our plans for a 9.2 final release date? If we wait until
September 1 to release our first release candidate, we will probably not
release final until mid/late September. Is that what we want?

Personally I had hoped to see an earlier release date than that.

Me too, but we are running out of time ... it's already late July.

I think the immediate goal must be to clear the list of open issues
http://wiki.postgresql.org/wiki/PostgreSQL_9.2_Open_Items
and then get another beta out.

It looks like the most optimistic schedule we could possibly make,
assuming no show-stopper bugs are reported, is:

* Wrap beta3 on August 2 for release Monday Aug 6

* RC1 two weeks later (release Aug 20)

* 9.2.0 two weeks after that (release Sept 3)

Now that schedule isn't actually going to work so far as the USA
contingent is concerned, because Sept 3 is Labor Day. But we could
figure that there's room for one week's slip in there, either for
RC1 or final, giving us a release date of Sept 10.

Again, this is assuming no major bugs are found to force more slippage
or additional betas/RCs. But I think it's reasonable to shoot for
If All Goes Well.

Comments, objections?

regards, tom lane

On Sat, Jul 21, 2012 at 6:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

It looks like the most optimistic schedule we could possibly make,
assuming no show-stopper bugs are reported, is:

* Wrap beta3 on August 2 for release Monday Aug 6

* RC1 two weeks later (release Aug 20)

* 9.2.0 two weeks after that (release Sept 3)

Now that schedule isn't actually going to work so far as the USA
contingent is concerned, because Sept 3 is Labor Day. But we could
figure that there's room for one week's slip in there, either for
RC1 or final, giving us a release date of Sept 10.

Again, this is assuming no major bugs are found to force more slippage
or additional betas/RCs. But I think it's reasonable to shoot for
If All Goes Well.

Comments, objections?

Seems OK, but I think we need to work a little harder on evicting some
things from the list of open items. I don't think all of the things
listed in the blockers section really are, and I'm not sure what needs
to be done about some of the things that are there.

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

Robert Haas <robertmhaas@gmail.com> writes:

Seems OK, but I think we need to work a little harder on evicting some
things from the list of open items. I don't think all of the things
listed in the blockers section really are, and I'm not sure what needs
to be done about some of the things that are there.

I've got the libpq row processor thing. That and the CHECK NO INHERIT
syntax thing are definitely release-blockers, because we won't be able
to change such decisions post-release (well, we could, but the pain to
benefit ratio is bad). I guess the SPGiST vs HS issue is a blocker too.
A lot of the rest look like pre-existing bugs to me.

regards, tom lane

On Mon, Jul 23, 2012 at 10:29:06AM -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Seems OK, but I think we need to work a little harder on evicting some
things from the list of open items. I don't think all of the things
listed in the blockers section really are, and I'm not sure what needs
to be done about some of the things that are there.

I've got the libpq row processor thing. That and the CHECK NO INHERIT
syntax thing are definitely release-blockers, because we won't be able
to change such decisions post-release (well, we could, but the pain to
benefit ratio is bad). I guess the SPGiST vs HS issue is a blocker too.
A lot of the rest look like pre-existing bugs to me.

The only preexisting issues listed under "Blockers for 9.2" are "GiST indexes
vs fuzzy comparisons used by geometric types" and "Should we fix tuple limit
handling, or redefine 9.x behavior as correct?". Also, I'm not sure what
exactly the "keepalives" item indicates. Whether every regression deserves to
block the release is, of course, a separate question.

I think "WAL files which were restored from the archive are archived again" is
the thorniest regression, and we don't yet have a patch.

On Tue, Jul 24, 2012 at 4:10 AM, Noah Misch <noah@leadboat.com> wrote:

On Mon, Jul 23, 2012 at 10:29:06AM -0400, Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

Seems OK, but I think we need to work a little harder on evicting some
things from the list of open items. I don't think all of the things
listed in the blockers section really are, and I'm not sure what needs
to be done about some of the things that are there.

I've got the libpq row processor thing. That and the CHECK NO INHERIT
syntax thing are definitely release-blockers, because we won't be able
to change such decisions post-release (well, we could, but the pain to
benefit ratio is bad). I guess the SPGiST vs HS issue is a blocker too.
A lot of the rest look like pre-existing bugs to me.

The only preexisting issues listed under "Blockers for 9.2" are "GiST indexes
vs fuzzy comparisons used by geometric types" and "Should we fix tuple limit
handling, or redefine 9.x behavior as correct?". Also, I'm not sure what
exactly the "keepalives" item indicates. Whether every regression deserves to
block the release is, of course, a separate question.

I think "WAL files which were restored from the archive are archived again" is
the thorniest regression, and we don't yet have a patch.

Yep, that's really a problem. Will implement the patch.

Regards,

--
Fujii Masao