Hi, Thanks for contacting maintainers impacted by the new timeline scheme.
On 2024-11-02 18:35, 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 I agree on that. > * 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]. Moving the toolchain freeze before the transition freeze basically means making it 2 months longer, it will just drop the motivation and engagement of the toolchain people. Could we make those two extra months a soft freeze? For instance freezing the major version of corresponding toolchain packages, but still allowing maintainers to do other small changes without having to go through the unblock process? Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
