From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <adunstan(at)postgresql(dot)org>, pgbuildfarm(at)rjuju(dot)net |
Subject: | Re: what's going on with lapwing? |
Date: | 2025-03-06 18:52:42 |
Message-ID: | CA+TgmoZb_KDK4YhM2uxV6agO03yH6xnqL08qZbquw1-qtfneWg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 6, 2025 at 1:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If there were some trivial way to do that, it'd be more acceptable.
> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
> branches_to_build covers some adjacent territory, but its filtering
> options go the wrong way (only branches newer than X, whereas what
> we want here is only branches older than X); probably we could
> also address this with more options there.
Yes, that would be nice. I also think we should mandate the use of
that option for OS versions that are EOL for more than X years, for
some to-be-determined value of X, like maybe 3 or something. Right
now, in the absence of any policy, and in the absence also of any
agreement on what the policy should be, we have to have a huge mailing
list thread every time somebody wants to get rid of an OS. I think it
should just be automatic. We don't need to give up -- and IMHO
shouldn't give up -- on an OS the moment the vendor pulls the plug
either on a certain release or on the system in general, but we
shouldn't have to individually litigate every case, either. Right now
half of when we desupport an OS seems to boil down to when the hard
drive on the last remaining server anybody has access to finally dies,
but that leads to weird outcomes where some operating systems are not
tested even though they are still in active use and others continue to
get tested long after they are not. To me, it all just feels a bit too
random, and I think we would be well-served by being more intentional
about it.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-03-06 18:54:17 | Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) |
Previous Message | Álvaro Herrera | 2025-03-06 18:51:38 | Re: Simplify the logic a bit (src/bin/scripts/reindexdb.c) |