On Wed, Oct 12, 2016 at 12:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Oct 12, 2016 at 11:54 AM, Greg Stark <st...@mit.edu> wrote: >>> Fwiw I was considering proposing committing some patches for these old >>> releases to make them easier to build. I would suggest creating a tag >>> for a for this stable legacy version and limiting the commits to just: >>> >>> 1) Disabling warnings >>> 2) Fixing bugs in the configure scripts that occur on more recent >>> systems (version number parsing etc) >>> 3) Backporting things like the variable-length array code that prevents >>> building >>> 4) Adding compiler options like -fwrapv > >> I'd support that. The reason why we remove branches from support is >> so that we don't have to back-patch things to 10 or 15 branches when >> we have a bug fix. But that doesn't mean that we should prohibit all >> commits to those branches for any reason, and making it easier to test >> backward-compatibility when we want to do that seems like a good >> reason. > > Meh, I think that this will involve a great deal more work than it's > worth. We deal with moving-target platforms *all the time*. New compiler > optimizations break things, libraries such as OpenSSL whack things around, > other libraries such as uuid-ossp stop getting maintained and become > unusable on new platforms, bison decides to get stickier about comma > placement, yadda yadda yadda. How much of that work are we going to > back-port to dead branches? And to what extent is such effort going to be > self-defeating because the branch no longer behaves as it did back in the > day? > > If Greg wants to do this kind of work, he's got a commit bit. My position > is that we have a limited support lifespan for a reason, and I'm not going > to spend time on updating dead branches forever. To me, it's more useful > to test them in place on contemporary platforms. We've certainly got > enough old platforms laying about in the buildfarm and elsewhere.
I agree that it shouldn't be an expectation that committers in general will do this, whether you or me or anyone else. However, I think that if Greg or some other committer wants to volunteer their own time to do some of it, that is fine. -- 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
