XPost: linux.debian.maint.boot, linux.debian.kernel

Hi Sebastian,

[trimming bit recipents list + adding debian-kernel]

On Sat, Nov 02, 2024 at 06:35:53PM +0100, Sebastian Ramacher wrote:

Dear toolchain, debian-installer, and image maintainers,

We, as the release team, are aware that we are late with the
announcement of the freeze timeline for trixie. After some internal discussions on how we want to handle the freeze for trixie based on the lessons learnt from the bookworm release, we like to get your feedback
on our changes listed below before we announce the freeze schedule.

During the bookworm release we made the following observations:
* motivation and engagement of maintainers drop as the freeze becomes
longer
* the work on d-i and images takes time and requires a non-moving set of
packages to work on

To reduce the time that maintainers of packages not contained in the
build essential / toolchain set or packages that are somewhat relevant
for d-i are affected by the freeze, we hope to keep their engagement up
by delaying the transition and soft freeze, but freezing relevant
packages instead. We would like to get input from debian-boot to define
the relevant criteria so that the freeze is useful for them. We would
start with the following set

packages producing udebs
packages involved in a minimal debootstrap

In the following discussion we will simply call them "udeb producing packages" but better wording is more then welcome.

We thus propose the following timeline:

Milestone 1: Toolchain and d-i freeze

As in bookworm, we start with the freeze of toolchain with the goal to stabilize build essential packages and compilers and interpreters of
major ecosystems (Python, Ruby, Rust, Golang, Haskell, Vala, LLVM). The
list of packages that is involved can be found at [1].

In trixie we will also freeze all packages that produce udebs with the
intent to stabilize the relevant packages for debian-installer and debian-boot. Changes to these packages need to be coordinated with the respective teams. Effectively, this means that any change to a package producing udebs will require an unblock request with an explicit ACK
from d-i to migrate and we also won't be doing any transitions of udeb producing packages.

udeb producing packages maintained by debian-boot and debian-cd are
exempt from these rules to facilitate their work. Updates to these
packages should be prepared at their maintainers' discretion and are
expected to benefit the development of the installer.

How would you aim or envision the role of src:linux in this picture?
In past we still did the stable release rebases in unstable, beeing
more careful and in ocordination still with release team and d-i
folks, but this allowed to keep the pace on upstream stable versions
with bugfixes.

Do you still see this a posiblity for the coordination work between
release team, d-i, debian-boot and kernel updates?

Regards,
Salvatore

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