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
