Re: Upgrade Debian CI images to Bookworm

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Upgrade Debian CI images to Bookworm
Date: 2024-05-24 14:17:37
Message-ID: d16b6bf9-fbe3-43dc-bd12-4cd688b12816@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 13.05.24 12:57, Nazir Bilal Yavuz wrote:
> Bookworm versions of the Debian CI images are available now [0]. The
> patches to use these images are attached.
>
> 'v1-0001-Upgrade-Debian-CI-images-to-Bookworm_REL_16+.patch' patch can
> be applied to both upstream and REL_16 and all of the tasks finish
> successfully.
>
> 'v1-0001-Upgrade-Debian-CI-images-to-Bookworm_REL_15.patch' patch can
> be applied to REL_15 but it gives a compiler warning. The fix for this
> warning is proposed here [1]. After the fix is applied, all of the
> tasks finish successfully.
>
> Any kind of feedback would be appreciated.

These updates are very welcome and look straightforward enough.

I'm not sure what the backpatching expectations of this kind of thing
is. The history of this CI setup is relatively short, so this hasn't
been stressed too much. I see that we once backpatched the macOS
update, but that might have been all.

If we start backpatching this kind of thing, then this will grow as a
job over time. We'll have 5 or 6 branches to keep up to date, with
several operating systems. And once in a while we'll have to make
additional changes like this warning fix you mention here. I'm not sure
how much we want to take this on. Is there ongoing value in the CI
setup in backbranches?

With these patches, we could do either of the following:

1) We update only master and only after it branches for PG18. (The
update is a "new feature".)

2) We update only master but do it now. (This gives us the most amount
of buffer time before the next release.)

3) We update master and PG16 now. We ignore PG15.

4) We update master and PG16 now. We update PG15 whenever that warning
is fixed.

5) We update master, PG16, and PG15, but we hold all of them until the
warning in PG15 is fixed.

6) We update all of them now and let the warning in PG15 be fixed
independently.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-05-24 14:20:00 Re: DROP OWNED BY fails to clean out pg_init_privs grants
Previous Message Srinath Reddy Sadipiralla 2024-05-24 14:05:34 Re: Question: Why Are File Descriptors Not Closed and Accounted for PostgreSQL Backends?