On Wed, Dec 9, 2015 at 2:54 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.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 would say it's necessary but not sufficient. The other criterion I'd lay down is that you shouldn't need to really change anything in the code except maybe to fix up s_lock.h breakage or some equally minor wart. For example, suppose that somebody wanted a new platform which works just like UNIX except that open() takes 4 arguments instead of 3, and we've always got to pass 0 for the last one. Well, even though that's minor and easily done, I'm not going to argue for back-patching that to all supported branches. I don't think that would be good material for a back-patch; the necessary changes could flummox third-party code or just turn out to be buggy, and apparently this new platform wasn't that important up until now, so whatever. But I feel differently about this case because we basically already do support the platform, or so it seems. We just didn't know we supported it. Really, we expect our stuff to work anywhere that has a reasonably UNIX-like environment and, hey, it'll even use atomics automatically if it has a reasonably modern gcc. So, win. I don't think that we really gain anything by refusing to admit that the product works on a platform where it does work. We've put a lot of effort into being portable and I don't think we should feel bad about that. If we test PostgreSQL on a new platform and it works with no problems (or only trivial adjustments that seem like good back-patch candidates anyway), then I think it's fine to just say, yep, it works. I don't think that sets a precedent that we'll be willing to accept arbitrary changes in back-branches to make it work when it doesn't already. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
