Yes, I know the debian-installer is not a done deal, so kibi, please
let us know where you think we stand with d-i (briefly is OK, I know
you normally report extensively elsewhere) and when you think d-i can realistically be in a releasable state. (Saying: "in June" is fine,
than we can plan accordingly).
Hi Paul,
Paul Gevers <elbrus@debian.org> (2023-02-17):
Yes, I know the debian-installer is not a done deal, so kibi, please
let us know where you think we stand with d-i (briefly is OK, I know
you normally report extensively elsewhere) and when you think d-i can
realistically be in a releasable state. (Saying: "in June" is fine,
than we can plan accordingly).
----BEGIN VERY WILD GUESS----
With a release going out this week-end, I think the next one with
bugfixes or improvements based on user or developer feedback couldn't
happen before 2 weeks. And I'd expect 2 more releases after that to iron >things out, with at least 1 week between each.
That'd mean end of March, beginning April at the soonest.
Depending on what we encounter, and possible changes in other packages
in the archive, we might have various delays, so it's probably best to
add 2-4 extra weeks to that.
I'll let Steve comment on the bootloader aspect (brand new shim just
arrived, not sure how much time / how many iterations we might need to
get it in shape for bookworm; plus we've gotten some fixes in grub but I >think some further changes are planned).
What do people think of the idea
to start picking a release date already?
Adam, I think we'd also want to do a point release before that time,
e.g. to include a fix for bug #1029803. What do you think about it?
Sorry for the delayed reply, apparently I'm further behind than I
realised. :-(
On Fri, 2023-02-17 at 21:56 +0100, Paul Gevers wrote:
[...]
What do people think of the idea[...]
to start picking a release date already?
Adam, I think we'd also want to do a point release before that time,
e.g. to include a fix for bug #1029803. What do you think about it?
Yes. We also really want to get a debian-archive-keyring update into
bullseye before the release, or we can't use the new keys to sign the >bookworm release files. But first we need to get it into unstable. I'm
aware that we're very late here, sorry. :-(
ftp-master have now published their bookworm keys, so we can get those >incorporated. For the SRM side, you probably saw that we've been
considering moving to an EC key. From the very limited responses to the >discussion I started on debian-release, I'm still not entirely sure if
that's feasible / a good idea.
It would also be good to finally get the shim updates into bullseye at
the same time, unless Steve tells me that's a bad plan. :-)
ftp-master have now published their bookworm keys, so we can get those incorporated. For the SRM side, you probably saw that we've been
considering moving to an EC key. From the very limited responses to the discussion I started on debian-release, I'm still not entirely sure if
that's feasible / a good idea.
Hi Adam,
On Thu, 09 Mar 2023 17:05:28 +0000, Adam wrote:
ftp-master have now published their bookworm keys, so we can get those incorporated. For the SRM side, you probably saw that we've been considering moving to an EC key. From the very limited responses to the discussion I started on debian-release, I'm still not entirely sure if that's feasible / a good idea.
Does the signing method update have to be one-method-for-another, or
is there is a way to phase-in a new method before phasing-out the old?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 476 |
Nodes: | 16 (0 / 16) |
Uptime: | 166:23:50 |
Calls: | 9,513 |
Calls today: | 1 |
Files: | 13,639 |
Messages: | 6,130,859 |