Re: [CORE] Restore-reliability mode - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [CORE] Restore-reliability mode
Date
Msg-id CANP8+jJPyQLadtqrPJKrBVOEvK85nz+2oMk=CDAcUrwS-O-eNA@mail.gmail.com
Whole thread Raw
In response to Re: [CORE] Restore-reliability mode  (Josh Berkus <josh@agliodbs.com>)
Responses Re: [CORE] Restore-reliability mode  (Robert Haas <robertmhaas@gmail.com>)
Re: [CORE] Restore-reliability mode  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 3 June 2015 at 18:21, Josh Berkus <josh@agliodbs.com> wrote:
 
I would argue that if we delay 9.5 in order to do a 100% manual review
of code, without adding any new automated tests or other non-manual
tools for improving stability, then it's a waste of time; we might as
well just release the beta, and our users will find more issues than we
will.  I am concerned that if we declare a cleanup period, especially in
the middle of the summer, all that will happen is that the project will
go to sleep for an extra three months.

Agreed. Cleanup can occur while we release code for public testing.

Many eyeballs of Beta beats anything we can throw at it thru manual inspection. The whole problem of bugs is that they are mostly found by people trying to use the software. 
 
I will also point out that there is a major adoption cost to delaying
9.5.   Right now users are excited about UPSERT, big data, and extra
JSON features. If they have to wait another 7 months, they'll be a lot
less excited, and we'll lose more potential users to the new databases
and the MySQL forks. 

Reliability of having a release every year is important as well as
database reliability ... and for a lot of the new webdev generation,
PostgreSQL is already the most reliable piece of software infrastructure
they use.  So if we're going to have a cleanup delay, then let's please
make it an *intensive* cleanup delay, with specific goals, milestones,
and a schedule.  Otherwise, don't bother.

We've decided previously that having a fixed annual schedule was a good thing for the project. Getting the features that work into the hands of the people that want them is very important.

Discussing halting the development schedule publicly is very damaging. 

If there are features in doubt, lets do more work on them or just pull them now and return to the schedule. I don't really care which ones get canned as long as we return to the schedule.

Whatever we do must be exact and measurable. If its not, it means we haven't assembled enough evidence for action that is sufficiently directed to achieve the desired goal.


On 3 June 2015 at 18:21, Josh Berkus <josh@agliodbs.com> wrote:
 
  It could also delay the BDR project (Simon/Craig
can speak to this) which would suck.

Nothing being discussed here can/will slow down the BDR project since it is already a different thread of development. More so, 2ndQuadrant has zero income tied to the release of 9.5 or the commit of any feature, so as far as that company is concerned, the release could wait for 10 years.

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

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: "Shulgin, Oleksandr"
Date:
Subject: Handle PGRES_COPY_BOTH in psql for logical replication?