On Tue, Jan 23, 2024 at 02:02:15AM -0800, Simon Chopin wrote: > Hi Release Team,
> 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. You use the past tense here; https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 shows glibc 2.39 for this week. Did this projection change, and in which direction? FWIW I've just added 64-bit time_t onto the page, estimating that it will start to happen next week. There are some externalities there not directly under our control, specifically the timing of the upload of dpkg to unstable and the analysis of the uploads to experimental (which are currently in progress) with respect to usrmerge. I had asked about making sure the perl and python transitions complete before 64-bit time_t lands in noble, because I don't want these to overlap; and my intention is to turn off Debian autosyncs if necessary until perl and python migrate. But I don't think there's the same concern about glibc (it's just a new upstream version with new symbols rather than a transition), so I'm not going to argue for postponing either glibc 2.39 or 64-bit time_t to avoid entanglement. > 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. > 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. "presumably" - usually, the new symbols from one release to the next are small and don't affect too many packages. Can you give us a list of new symbols in 2.39, to understand how significant this is? Because there's a tension here between wanting packages to pick up the new interfaces, and wanting unrelated uploads of packages to not get stuck behind glibc in -proposed if the migration takes a long time. > * 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. > WDYT? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
