• Timing around last updates for src:linux targetting bookworm

    From Salvatore Bonaccorso@21:1/5 to All on Wed May 3 18:20:01 2023
    Hi

    [Cc'ed explicitly Ben and Cyril]

    With the planned release date for 2023-06-10 and dates around that as
    announced by the release time it's time to clarify some last work for
    src:linux to be targeted for bookworm.

    The base details are in https://lists.debian.org/debian-devel-announce/2023/04/msg00007.html
    The full freeze date will be on 2023-05-24. Additionally we need to
    take into account the Debian d-i plannings by Cyril and debian-boot.

    Foremost, Paul Gevers stated in https://bugs.debian.org/1034446#14
    what is okay and for how long:

    I'm pretty sure I've mentioned this to you before, but to be clear to everybody I'll state it in public here: we currently trust the kernel maintainers to make the right decision until (around) the full freeze
    under the condition that they consider the following:

    * would you propose the same for a point release?
    * if activity in the archive on the d-i front is ongoing or expected
    check with d-boot.

    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.

    Given the merge window for 6.4, and 6.4-rc1 upcoming, the stable
    releases following that are quite big, and I fear we should skip those
    for bookworm initial version, meaning we need to stop before that.

    Preliminary work on this is at https://salsa.debian.org/kernel-team/linux/-/merge_requests/707 (at
    time of writing updated up to 6.1.27 upstream).

    Additionally to that there are some requests which are still okay to
    be included for bookworm: https://salsa.debian.org/kernel-team/linux/-/merge_requests/710
    which Ben already stated to be wanted in bookworm.
    HW support from Aurelien in https://salsa.debian.org/kernel-team/linux/-/merge_requests/711

    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?

    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?

    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.

    Are we yet missing anything crucial for the release?

    Opinion, comments, acks or nacks or specific items?

    Regards,
    Salvatore

    -----BEGIN PGP SIGNATURE-----

    iQKTBAABCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmRSiBNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2 NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xND z0QbYw/+LFlS1jYUDRkqZuVsglFCVDA+A0MJYBGYtbIeLRpn3lh0ECbX4Q/jjByB j6NCq5g+3mBj9k5HfU2HmXBpnqHr4sfJeDIs6q3o5fhOrk7cnpHVxk0IuPJD5F3q 6QcdK34SWE4sO5w+BLoMK5JJOqkUdnZhsig//uhO+Ihm5JxIil9igGpNZo5rg8k2 Xcb0t26t8tKeu8iMfFJsv5PB0uudFrqmjGvkLz896dzBiVW9RnImncIQ3HHYc6iH Oc59aLUGZ+XNDDAlKs435ovLYPRqxJQpkHQbCDqHXTTIdna5EFSOLjjDYllmkIva WrygCiZ16Jy8OpcgW9lOUePyNMS7Ws14BTw3V/HdGrYA6HXNbfHamef6xsvWwM+w qCk4dzXukuqvJWEePWBG9X5FbxB1mJJ68NsSdmIDHQ5P4BY5vdatC8FPLlunhRFp eZ7YUzAtjFlfJsuIdPR5ybyUVMckEpjSa9S88swIgz7q9DmuX6GJ+9Qp20QwxX6x urfPxANo8E7psuimZZnD2KXDi1BXxyTlCGczZLdGAec47QNcY9+BhdmbLU0vbSF5 UvtFjFXfINjlnpUlk8iKQlqT4mGcEsNJNYQbNJtp+sO1CMtY3rr+TB9wHAJxJbNh Q+T9Zxc8otlnM5PxwDji7gyfOGnuj2EscHZsAsCAA3u7j3Raxp4=
    =sNNU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Cyril Brulebois@21:1/5 to All on Thu May 4 02:40:01 2023
    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
    *
  • From Emanuele Rocca@21:1/5 to Salvatore Bonaccorso on Fri May 5 21:40:04 2023
    Hi Salvatore,

    On Wed, May 03, 2023 at 06:13:22PM +0200, Salvatore Bonaccorso wrote:
    With the planned release date for 2023-06-10 and dates around that as announced by the release time it's time to clarify some last work for src:linux to be targeted for bookworm.

    [...]

    Additionally to that there are some requests which are still okay to
    be included for bookworm: https://salsa.debian.org/kernel-team/linux/-/merge_requests/710
    which Ben already stated to be wanted in bookworm.
    HW support from Aurelien in https://salsa.debian.org/kernel-team/linux/-/merge_requests/711

    [...]

    Are we yet missing anything crucial for the release?

    Not crucial of course but I'd really like to get this hardware support patch in, if at all possible. Sorry for the last minute request! https://salsa.debian.org/kernel-team/linux/-/merge_requests/712

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvatore Bonaccorso@21:1/5 to Emanuele Rocca on Sat May 6 10:30:01 2023
    Hi Emanuele,

    On Fri, May 05, 2023 at 09:34:23PM +0200, Emanuele Rocca wrote:
    Hi Salvatore,

    On Wed, May 03, 2023 at 06:13:22PM +0200, Salvatore Bonaccorso wrote:
    With the planned release date for 2023-06-10 and dates around that as announced by the release time it's time to clarify some last work for src:linux to be targeted for bookworm.

    [...]

    Additionally to that there are some requests which are still okay to
    be included for bookworm: https://salsa.debian.org/kernel-team/linux/-/merge_requests/710
    which Ben already stated to be wanted in bookworm.
    HW support from Aurelien in https://salsa.debian.org/kernel-team/linux/-/merge_requests/711

    [...]

    Are we yet missing anything crucial for the release?

    Not crucial of course but I'd really like to get this hardware support patch in, if at all possible. Sorry for the last minute request! https://salsa.debian.org/kernel-team/linux/-/merge_requests/712

    Ok! Given the explicit 'ack/looks good' from Vagrant Cascadian, I have
    merged in that as well.

    Regards,
    Salvatore

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)