Re: Include ppc64le build type for back branches

On Tue, Dec 8, 2015 at 1:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I don't really want to get into an argument about this, but is the
>> reason we haven't updated config.guess and config.sub in the past that
>> it presents an actual stability risk, or just that nobody's asked
>> before?  Because the first one is a good reason not to do it now, but
>> the second one isn't.
>
> Well, I see at least one case in the git history where we explicitly
> declined to update config.guess/config.sub:
>
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Branch: master Release: REL9_3_BR [5c7603c31] 2013-06-04 15:42:02 -0400
> Branch: REL9_2_STABLE Release: REL9_2_5 [612ecf311] 2013-06-04 15:42:21 -0400
>
>     Add ARM64 (aarch64) support to s_lock.h.
>
>     Use the same gcc atomic functions as we do on newer ARM chips.
>     (Basically this is a copy and paste of the __arm__ code block,
>     but omitting the SWPB option since that definitely won't work.)
>
>     Back-patch to 9.2.  The patch would work further back, but we'd also
>     need to update config.guess/config.sub in older branches to make them
>     build out-of-the-box, and there hasn't been demand for it.
>
>     Mark Salter

Right, but that commit cites lack of demand, rather than anything else.

> More generally, I think "does updating config.guess, in itself, pose
> a stability risk" is a false statement of the issue.  The real issue is
> do we want to start supporting a new platform in 9.1-9.3; that is, IMO
> if we accept this request then we are buying into doing *whatever is
> needed* to support ppc64le on those branches.  Maybe that will stop with
> config.guess/config.sub, or maybe it won't.

I'm sympathetic to that concern.  On the other hand, if somebody were
to discover, say, a bug in s_lock.h that causes a compile failure on
ppcle, I think we'd treat that as a back-patchable fix and whack it
into all supported branches.  If somebody were to come along and say,
you can't use GetWeirdWindowsCrap() on the latest verison of Windows,
you have to instead use GetDumbWindowsCrap(), we would presumably
back-patch that as far as convenient also.  Are those kind of changes
adding support for a new platform, or just fixing bugs?  Now, on the
flip side, the original port to Windows was not back-patched, nor
should it have been: that was clearly major new development, not just
tweaking.

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.  On the other hand, maybe it'd be better
to get the buildfarm critter set up first (using the workaround Andrew
suggested) and then reevaluate.  If it seems to work, I see little
harm in saying, oh yeah sure it's supported, but we don't actually
know that yet.

> Setting this precedent will also make it quite hard to reject future
> requests to back-patch support for other new platforms.
>
> I'm not planning to go to war about this issue either.  But I do think
> there's a slippery-slope hazard here, and we should be prepared for
> the logical consequences of accepting such a request.  Or if we're
> going to have a policy allowing this request but not every such request,
> somebody had better enunciate what that policy is.

I don't have a real clear opinion about this just at the moment, but I
think "those changes look scary to back-patch" is a pretty decent
heuristic.  "That looks like new development" is another one I'd feel
confident to deploy.

> (BTW, so far as direct stability hazards go, I would guess that the
> key question is how much version skew can be tolerated between autoconf
> and config.guess/config.sub. I have no idea about that; Peter E. might.
> But I do note that pre-9.4 branches use an older autoconf version.)

That's a good question, and I wonder if this is why it works from 9.4.
I don't remember an explicit decision to begin supporting ppcle, and
I'm not sure in any case that I'd endorse the view that whatever
config.guess has heard of, we support.  I thought the policy was more
like "whatever we have a working BF member for, we support".

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company