Re: what's going on with lapwing?
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <adunstan@postgresql.org>, pgbuildfarm@rjuju.net
Date: 2025-03-06T21:38:30Z
Lists: pgsql-hackers
On Thu, Mar 6, 2025 at 4:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I think you misunderstood my drift. I'm okay with setting a project > policy that we won't support OSes that are more than N years EOL, > as long as it's phrased to account for older PG branches properly. Yep, I misunderstood. That sounds awesome. Let's see if others agree. > My point was that we can implement such a policy in a laissez-faire > way: if an older BF animal isn't causing us trouble then why mess > with it? Once we *do* recognize that it's causing us trouble, > we can apply the still-hypothetical policy and ask the owner to > turn it off for branches where it's out of support. Fair enough. This does have the disadvantage that people will still commit things that turn the buildfarm red and have to go into panic mode -- perhaps not even realizing which machines are running an older OS -- and then reactively do this. However, it still sounds like progress over where we are today, because it would (hopefully) remove the need for an argument about each individual case. Honestly, I'm kind of bummed by how fast operating systems and OS versions die these days. It seems crazy to me that I probably couldn't reasonably build a PG from today on the laptop I started at EDB with, or a PG from then on my current laptop. But it doesn't seem like there's much point in fighting the tide. We shouldn't be the only people trying to keep stuff working long after the sell-by date. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Revert workarounds for -Wmissing-braces false positives on old GCC
- 618c64ffd396 18.0 landed
-
Convert sepgsql tests to TAP
- aeb8ea361a0a 18.0 cited