Re: Include ppc64le build type for back branches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Sandeep Thakkar <sandeep(dot)thakkar(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Include ppc64le build type for back branches
Date: 2015-12-09 07:54:27
Message-ID: 4217.1449647667@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> With respect to this particular thing, it's hard for me to imagine
> that anything will go wrong on ppcle that we wouldn't consider a
> back-patchable fix, so there might be no harm in adjusting
> config.guess and config.sub.

FWIW, I also suspect that supporting ppc64le would not really take
much more than updating config.guess/config.sub; there's no evidence
in the git logs that we had to fix anything else in the newer branches.

My concern here is about establishing project policy about whether
we will or won't consider back-patching support for newer platforms.
I think that the default answer should be "no", and I'd like to
see us set down some rules about what it takes to override that.

Obviously, setting up a buildfarm member helps a good deal. But
is that sufficient, or necessary?

> I'm not sure in any case that I'd endorse the view that whatever
> config.guess has heard of, we support.

config.guess support is a necessary but certainly not sufficient
condition.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-12-09 08:22:38 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Etsuro Fujita 2015-12-09 07:52:30 Re: Remaining 9.5 open items