Hi all, Current status ============== Some of you might have read bits and pieces here and there, but I thought I'd share my plans a little more formally with some teams. As anticipated, it seems the last bits from the release team on dda@ got some attention, and we've been receiving many more installation reports than previously. Some of those reports are directly actionable, and various fixes are flowing in a bunch of components; some of them trigger some kind of chain reaction, and might end up leading to fixes via a point release instead. Installation reports have been mostly positive, and I'm not aware of any critical bug that would jeopardize the proposed timeline. \o/ For those who want to follow at home, I have a list of things I'm tracking and that might be fixed or at least considered before 12.0.0; nothing is mandatory in there! https://salsa.debian.org/installer-team/debian-installer/-/issues/1 Proposed plan ============= I think it'd make sense to have at least 2 releases: - 1 around mid-May; - 1 around end of May. The first one would bundle a bunch of the fixes or improvements being worked on these days, making sure everything works as intended. The second one would be an “everything is frozen, we upload d-i one last time” release, which could include a few last-minute fixes or improvements if required or desired. This means we should be able to pick whatever linux kernel is in testing for the first release, while the kernel team prepares the final linux upload on their own accord, which we'll pick up with the second release. Communication and dynamics between the installer and kernel teams are well-established and give good results, see earlier discussion: https://lists.debian.org/debian-kernel/2023/05/msg00031.html https://lists.debian.org/debian-kernel/2023/05/msg00043.html Salvatore had good questions about how to best handle possible critical fixes (security or otherwise) during the last few days, and whether bookworm-security would make sense if that happened. On the installer side I'm happy to work with whatever ends up in testing (via unstable or t-p-u), but we don't currently support building or running d-i against security suites (the former is probably trivial, the latter might be very tricky). I'm also not sure how going through security would factor in when it's time to build final images (12.0.0). But maybe we can think about it if and when we actually encounter such problems. I'm happy to touch base with the release team again when we approach end of May, to see what would be considered best for the (hopefully) final d-i upload (and d-i-n-i, at least a dinstall afterward). It might make sense not to wait too much before doing so, in case we end up having to fix a package or two, and re-upload… Regarding the final release, I'm happy to perform a final d-i upload if some packages needed an update since RC 4… but hopefully the last build can be reused without any changes. Interactions with other teams ============================= You might have noticed the `dak copy-installer` step that copies the `installer-<arch>/` directories from unstable to testing is now something that I can trigger on my own, which gives us some appreciated flexibility: contrary to point releases that are planned and frozen in advance, testing keeps evolving (less so with the freeze progressing) and I couldn't really set fixed dates in advance so that various teams would be on stand-by… The other major team involved is debian-cd, and Steve and I usually come up with a set of days where both of us are available, and image building starts whenever the right bits have reached testing (the d-i package via britney, the `installer-<arch>/` directories via dak). I've been in the debian-cd group for a long while, but I've only been taught a crash-course recently on how to operate a d-i release and I should be able to operate one or two on my own. [ In the context of debian-cd, I'm calling a “d-i release” one of the “D-I $CODENAME Alpha|RC $N” releases; as opposed to initial stable releases (e.g. 12.0.0) or point releases (e.g. 11.7.0), which involve more work, lots of testers, the press team, etc. I wouldn't call myself ready for those just yet… ] This gives me a little more work but also some more flexibility as to when RC 3 and RC 4 happen. A side-effect, with regular d-i builds and live builds being started together when building images for a d-i release, is that I'll have to keep an eye on the live images as well. As mentioned to Jonathan earlier this week, my focus has only ever been on d-i itself (which keeps me busy already, and I'm not trying to wear yet another hat), and that shouldn't change in the near future, but I'm more than happy to keep an eye on debian-live needs, and wait for an extra package or an extra commit in live-setup.git before starting building images for a d-i RC (see things like #1035360 and #1035560). I don't think I'll be actively polling debian-live for input though; I'm more than happy to be told what is important (so that it can be tracked via the Salsa issue mentioned above, or one of the “point release variations”, see issues 2 and 3). I'm usually sharing progress towards a d-i release on IRC on #debian-boot, before moving to #debian-cd. I know at least Jonathan is present in both channels so we should be good; I'm happy to consider alternatives if needed though. Back to d-i, we have the release announcements going to dda@ and to the website, and I'm autonomous on both counts as usual. For the final release, I'll step back (even if d-i gets a final upload), and let you folks organize the Bookworm announcement. Conclusion ========== I'm happy to answer any questions you might have, and to amend my plans if you'd like some things to be done differently. Thanks for your time and attention, that's quite a long mail… With the release approaching, I thought it'd make sense to be as explicit as possible to make sure everyone is on the same page. Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature