Hi Graham, > > 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.
That's essentially what I meant, I tend to think of Feature Freeze as a singular event that includes turning off the auto-sync, perhaps wrongly so. Even if I wouldn't *technically* need a FFe, I'd still prefer RT approval since it has a rather large impact on the whole release process. > 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 -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
