Hi Salvatore,
Salvatore Bonaccorso <
carnil@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 (
kibi@debian.org) <
https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmRS/iUACgkQ/5FK8MKz VSDzSA//TflJDEezZEx9G/49LIXgr5JImJoNWuH15ZRNQvsxTwmpO5+vm+ALpyeL IBrceR1RzXj+PSPav4uKhSpKr2wyEbMztoBFwLXiPR7U0d42QoF6CzGJ1dkSPgZ/ SUDffn2+OKCpt9huxoCfYCjAAGQvMmdK6pm8aUn0ozwotp9dwlUB6m5WRkDoKntr oLnj1sDpZ9fPZPSRrawjVslGWm+1tANrOLKPah/apvYf3LdT7n53I6dIHoHwZqxF xJYWpSLZYlPNZJ6MJ7k5+juow4kZcecHeNs1okpXQLSE5rhKMBodHKbb9Aw9Zau0 p//NVdFHNG3NXV9u8jbeNBB60VCHteSkormfuEBPN9bIFikNykLY24wG6XOZ313Y tpeZMZshqUg0/3p8m2CH6bGRZ4ogVRJ602nKA/6RGlpTRM3ZmCEHr8NItTxdrGHh HqZF+U9jDg2IkzROPD2XqFPnEt4fAv/vjYSb/aUlvKkbMdL2RLq01QpRWqrAo+wV stZqh1EKcIuwl0MDxw89PIAIZv3zgB0GyLtD1NntCaRQc3C7sR4hypgnuWYHFaHf 96HF1Hg5e4g+aBQ5eezFaKSK1BEnYNZsBnOsaklR6Qx3eQcLKVQCAcnmh90A0USa W/09GD3ZHadoVjw0buTDEHhq8oyaWB3J65dpQ+SabRyBRXJ2J4o=
=fcNC
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
*