On 2025-03-06 Th 2:28 PM, Andres Freund wrote:
> Hi,
>
> On 2025-03-06 14:13:40 -0500, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Thu, Mar 6, 2025 at 1:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Maybe invent a build-farm.conf option like "newest_branch_to_build"?
>>> 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.
>> It's hard to "mandate" anything in a distributed project like this.
>> I don't really see a need to either, at least for cases where an
>> old animal isn't causing us extra work.
> Lapwing *has* caused extra work though, repeatedly.
>
>
>> When it does, though, it'd be nice to be able to decide "we're not gonna
>> support that OS version beyond PG nn", and then have a simple recipe to give
>> the BF owner that's less drastic than "shut it down".
> The BF is there to be useful for PG development. BF owners contribute them for
> that purpose. I don't think we need to keep animals alive when they're past
> their shelf life, just to make the animal's owners happy - I suspect most
> won't want to keep an animal alive that we don't want.
>
> That said, I'd be happy if the BF had a slightly easier way to configure "up
> to this major version".
>
The only reason it's not there is that nobody's ever asked for it ;-)
You can specify an actual list right now instead of a keyword for
branches_to_build. e.g. "branches_to_build => [qw(REL_13_STABLE
REL_14_STABLE REL_15_STABLE)]". The only difficulty about this is you
need to prune the list when a branch goes EOL.
But we could also build in some keyword type settings too, that would
interact more sensibly with the server list of branches.
So we could say something like "branches_to_build =>
'UP_TO_REL_15_STABLE'". That would be pretty simple to code for.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
