Transition entanglement: delay glibc upload?

[Graham Inggs]

Hi Simon

On Tue, 23 Jan 2024 at 12:03, Simon Chopin <simon.chopin at canonical.com> wrote:
> It seems we have a few big transitions either in progress (perl,
> python) or about to start in the coming weeks (php, armhf 64bit time_t).
> My original plans for glibc would add fuel to that fire, as I projected
> to upload it to -proposed in about 2 weeks.
>
> A possible way to reduce the friction introduced by a new glibc verison
> would be to delay it until after Feature Freeze: fewer packages would
> pick up the new symbols and thus wouldn't get blocked waiting for the
> glibc rdeps autopkgtests to clear.

Does it need to be after Feature Freeze?

You could co-ordinate your upload with the release team such that it
happens on the day of Feature Freeze, but after the auto-sync from
Debian is disabled.  I don't think you'd even need a Feature Freeze
exception for that.

If I'm reading glibc's publishing history [1] correctly, 2.37-0ubuntu1
was uploaded to Lunar on 2023-02-03, but only migrated on 2023-03-11,
after Feature Freeze, which was on 2023-02-23.

2.37-0ubuntu2 was uploaded to Lunar on 2023-03-16 and migrated on 2023-03-27.

It would be interesting to compare these dates if we do things
differently for Noble.

> I can see a couple of downsides to that approach:
>
> * Fewer packages would pick the new ABIs, which presumably bring in some
>   sort of improvement in one form or another.
> * The newer glibc would be tested for less time, although presumably
>   that's somewhat offset by it taking less time to reach the release
>   pocket from -proposed.

I would guess glibc would migrate around the same date, whether it was
uploaded tthree weeks before or on Feature Freeze, so it would get
about the same amount of testing in the release.

Regards
Graham


[1] https://launchpad.net/ubuntu/+source/glibc/+publishinghistory