On 05/31/2017 07:49 AM, Robert Haas wrote:
On Tue, May 30, 2017 at 9:12 PM, Craig Ringer <cr...@2ndquadrant.com> wrote:
Thoughts? Backpatch new TAP methods, etc, into back branches routinely?
[...]
When customers start to doubt that, then they
become reluctant to apply new minor versions in their entirety and ask
for individual commits to be cherry-picked, or just don't upgrade at
all.
This may be true, on the other hand that isn't .Org's problem. Customers
are CMD, EDB, 2Qs problem. .Org's problem is: How do we ensure the best
possible result for PostgreSQL.
I think comprehensive testing (which I am sure you agree) is bullet
point on that list.
One could argue that commits to the testing framework shouldn't
make customers nervous, but what people should be worried about and
what they are actually worried about do not always match. It is
useful to be able to show a customer a list of things that were done
in a minor release and see nothing in there that can be described as
optional tinkering.
This is about narrative. You don't say "optional tinkering". You say,
"Initiate code modification for comprehensive TAP (testing) framework".
That makes customers knees weak and they swoon.
back-patching (to avoid churning a supposedly-stable branch). I'm not
sure exactly what I think about this issue, but I'm very skeptical of
the idea that back-patching less conservatively will have no
downsides.
There is never not a downside. The question is, "Does the upside
outweigh the downside?". In this case I would argue it is fairly obvious.
Thanks,
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
Unless otherwise stated, opinions are my own.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
