Re: [CORE] postpone next week's release - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [CORE] postpone next week's release
Date
Msg-id CANP8+jLmNN6uD7qhjRjepXK0Zsxiokc_Av18Qz0_rVd0aVgh6w@mail.gmail.com
Whole thread Raw
In response to Re: [CORE] postpone next week's release  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 30 May 2015 at 05:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 29, 2015 at 6:33 PM, Andres Freund <andres@anarazel.de> wrote:
>> Why? A large portion of the input required to go from beta towards a
>> release is from actual users. To see when things break, what confuses
>> them and such.

> I have two concerns:

> 1. I'm concerned that once we release beta, any idea about reverting a
> feature or fixing something that is broken will get harder, because
> people will say "well, we can't do that after we've released a beta".
> I confess to particularly wanting a solution to the item listed as
> "custom-join has no way to construct Plan nodes of child Path nodes",
> the history of which I'll avoid recapitulating until I'm sure I can do
> it while maintaining my blood pressure at safe levels.

> 2. Also, if we're going to make significant multixact-related changes
> to 9.5 to try to improve reliability, as you proposed on the other
> thread, then it would be nice to do that before beta, so that it gets
> tested.  Of course, someone is bound to point out that we could make
> those changes in time for beta2, and people could test that.  But in
> practice I think that'll just mean that stuff is only out there for
> let's say 2 months before we put it in a major release, which ain't
> much.

I think your position is completely nuts.  The GROUPING SETS code is
desperately in need of testing.  The custom-plan code is desperately
in need of fixing and testing.  The multixact code is desperately
in need of testing.  The open-items list has several other problems
besides those.  All of those problems are independent.  If we insist
on tackling them serially rather than in parallel, 9.5 might not come
out till 2017.

I agree that we are not in a position to promise features won't change.
So let's call it an alpha not a beta --- but for heaven's sake let's
try to move forward on all these issues, not just some of them.

I think releasing 9.5 in some form NOW will aid its software quality.

We've never linked Beta release date to final release date, so if the quality proves to be as poor as some people think then the list of bugs will show that and we release later. 

AFAIK beta period is exactly the time when we are allowed to pull features from the release. I welcome the idea that we test it, if its stable and it works we release it. If doesn't, we pull it.

Not releasing our software yet making a list of our fears doesn't work towards a solution. Our fears will make us shout at each other too, so I for one would rather skip that part and do some practical actions.

--
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [CORE] postpone next week's release
Next
From: Kouhei Kaigai
Date:
Subject: Re: Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)