Re: [CORE] Restore-reliability mode
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>,
Noah Misch <noah@leadboat.com>, Bruce Momjian <bruce@momjian.us>,
Andres Freund <andres@anarazel.de>,
Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>,
Magnus Hagander <magnus@hagander.net>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
pgsql-core <pgsql-core@postgresql.org>
Date: 2015-06-05T15:18:41Z
Lists: pgsql-hackers
On 5 June 2015 at 15:00, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Jun 5, 2015 at 2:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > Agreed. Cleanup can occur while we release code for public testing. > > The code is available for public testing right now. People test when they get the signal from us, not before. While what you say is literally correct, that is not the point. > Stamping it a > beta implies that we think it's something fairly stable that we'd be > pretty happy to release if things go well, which is a higher bar to > clear. > We don't have a clear definition of what Beta means. For me, Beta has always meant "trial software, please test". I don't think anybody will say anything bad about us if we release a beta and then later pull some of the features because we are not confident with them when AFTER testing the feature is shown to be below our normal standard; that will bring us credit, I feel. It is extremely common in software development to defer some of the features if their goals aren't met, or to change APIs and interfaces based upon user feedback. Making decisions on what will definitely be in a release BEFORE testing and feedback seems foolhardy and certainly not scientific. None of this means I disagree with assessments of the current state of the software, I'm saying that we should simply follow the normal process and stick to the schedule we have previously agreed, for all of the reasons cited when we agreed it. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add Valgrind buffer access instrumentation.
- 1e0dfd166b3f 14.0 landed
-
Fix wrong merge resolution making pg_receivexlog fail in 9.2.
- 6b700301c36e 9.2.11 cited