Re: TAP backpatching policy

On 05/31/2017 07:49 AM, Robert Haas wrote:
> On Tue, May 30, 2017 at 9:12 PM, Craig Ringer <craig(at)2ndquadrant(dot)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.