[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Upcoming D-I Bookworm RC 4 and pseudo-RC 5

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

> 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.

 - 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…

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: