Hi Salvatore, Salvatore Bonaccorso <car...@debian.org> (2023-05-03): > That means, I still would like to merge the next stable releases. The > latest point, depending on d-i planning would probably be sometime in > the week of the 15th may for a last upload targetting bookworm.
I don't have a clear schedule for RC 3 and RC 4 on the installer side, but I think I'd like to have RC 3 mid-May, and RC 4 later this month. How exactly the debian-installer(|-netboot-images) uploads integrate with testing's being completely frozen remains to be determined with the release team. The usual plan would be to have the installer prepared for the last RC (likely RC 4 here this year) be reused for the final release. Unless we really need to fix something, in which case the release team is likely to determine how they want that to be handled. > Open is how we handle #1033058. We added the patch from Cyril, but > this got rejected upstream. I think it would be better to not diverge > for too long from upstream, but AFAIK there was no progress on "the > real fix". Should we revert but then have a regression for the ppc6el > installer? Would that be affordable given the non-graphical installer > AFAIU still works? Cyril, what is your prefered take on this? If at all possible, I'd prefer for us _not_ to release a known broken ppc64el installer for 12.0. My plan was to monitor the situation, hoping people having introduced the regression would finally fix the fallouts, so that we could revisit for 12.1 or 12.2, hopefully replacing the (rejected) workaround with a real fix: https://salsa.debian.org/installer-team/debian-installer/-/issues/3 Coming up with a real fix on my own would likely require some time, and that's definitely not something I can afford at the moment (esp. with a workaround available… which is not even a plain revert of the commit triggering the regression — but that would have been fine with me as well!). To give some perspective, here's what's on my radar for 12.0: https://salsa.debian.org/installer-team/debian-installer/-/issues/1 > One question is how to handle (if some arise) severe security fixes > needed for src:linux in the time were we should not upload. I was > thinking if necessary to use bookworm-security for this already then > and not influencing any d-i work further. Cyril, what do you think? It > is really meant just in case we *need* to have an update, my prefered > way would be to not have to. What about updates with ABI bumps? I think we should be able to accommodate anything on the d-i side. Assuming the tentative and approximate schedule for RC 3 and RC 4 holds, if you need an immediate update of the kernel in testing, we can postpone the upcoming RC by a few hours or days, and wait for the updated kernel to be available in testing. If the release process has started (say debian-installer was uploaded, built, but we haven't built or published installation images yet), it's easy enough to stop everything, and restart when the kernel is ready. Whether we would want to do that (as opposed to finishing what was started already) is likely to depend on the nature of the bugs you want to fix. For example, if the kernel available in testing at the time is now getting reports about bricking some GPUs, or corrupting data on disk, it seems very wise to get a fix first, instead of pushing that to users via d-i! If in doubt, I'd suggest getting in touch with either the release team or the security team to find the right balance. d-i will follow (unless you introduce a big bad regression in case we'll want some bugfix)! > So in short: I propose (depending on concrete d-i plannings) to make > last possible upload latest in the week of 15th May. Open is what we > still would like to include. I'm afraid I don't have concrete or fixed/absolute d-i plannings at the moment, but the good news is that I'm (always I think) quite flexible regarding each release. “When it's ready” is basically how I've been doing it for a while. This is really “when I have time, and when things look good enough”, and it might take a few hours or days to settle all the things. The kernel being a very important part of the picture, I'm happy to use a slightly older version available in testing (that's what happened for RC 2), or to wait a little more for a newer version to become available (letting it age in unstable, or waiting for some critical bugfixes to become available). That could happen for RC 3 and/or RC 4, and that would be fine! Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
