Hi all, Cyril Brulebois <kibi@debian.org> (2023-05-21): > Dates that have been announced[1] so far: > - 2023-05-24: full freeze [x] ← You are here! > - 2023-05-28: last moment to file unblock requests > - 2023-06-03: bookworm totally frozen > (per “last week prior to the release”) > > 1. https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html > > On the d-i side, we'll have a round of translation updates, along > with some last tweaks, before RC 4. We should be all done in a few hours. I might pick a last minute tasksel change as well (for lxqt); I think it would help, could break, but that would be trivially revertable (and there would be room to do so, see below). > As far as I understand, at least at the moment, we aren't expecting a > new linux upload before the release. But if the need arises, we should > be able to deal with it. Checked with Salvatore: still no upload planned before the release. > I'm not sure what the best timeline would be for RC 4. Let's consider > two options: > - [Soon] Example: May 25. > - [Later] Window: May 28 - June 3. No preferences have been expressed by the release team during today's meeting. > In the first case, we would have a little more time to sort incoming > installation reports, and to react if needed. We might need a final > upload of debian-installer(-netboot-images). I think I'll go for this one, aiming for May 25 or May 26 unless some issues pop up. We know we have at least the apt vs. adduser issue that's going to get resolved, and I'd prefer not to wait for it, and also not to rush the update into testing… Also, we might have other packages that directly (because they produce udebs) or indirectly (because they're installed on every system, like apt) affect the installer or the installation process… migrate to testing later on. Let's consider a last debian-installer(-netboot-images) upload once Bookworm is definitely frozen, maybe a few days before the release to minimize the chances of having to consider a last-minute critical bugfix. Once it's in testing, we could even build images like we would for “D-I Bookworm RC 5”, just to be on the extra safe side. Those could be fetched by testers, but wouldn't be signed or announced (keeping them in the “usual dot directory”, deleting them a few days later). That would give us some extra peace of mind for the actual 12.0.0 images build that will happen on release day. It looks to me this would combine the best of two worlds: - Not wait too much before RC 4, leaving us some more days to deal with incoming reports; - Minimize risks of merging final changes in Bookworm, by having this “canary” RC 5 release. Notes: - This would be different from what we did for Bullseye, where we had an RC 3 built using debian-installer 20210731, which was then reused as is for the 11.0.0 images build. - This would be different from what we did for Buster, where we had an RC 3 built using debian-installer 20190702, which was then reused as is for the 10.0.0 images build. - Given each D-I release is “lighter” than a full release build (be it for an initial release or a point release), it seems to me going for RC 4 plus pseudo-RC 5 is cheap enough to buy us peace of mind than delaying RC 4 until we think (but still aren't sure) nothing is going to change in Bookworm. - Release early, release often! (even if late in the release cycle…) - I'm doing most of the work anyway… Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature