[To trimmed, since this is probably only interesting to Rust and RT people]
On Sat, Nov 2, 2024, at 6:35 PM, 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]. [Trimming the rest here since it's not relevant for Rust] If possible, it would be great to incorporate https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084048 into the freeze timeline in some way or another. W.r.t. the essential-and-build-essential list - it lists both cargo and rustc, which are built from the same source package nowadays, so maybe it's enough to just list rustc? It also lists debcargo, which only has two rdeps in the archive (both build and runtime). I'm fine if the inclusion on that list is supposed to signify "please don't change debcargo during the toolchain freeze and later stages of the freeze", even if it is only used on DD/DM machines to create source packages, and is not involved directly in building them. The archive freeze doesn't prevent anyone from using a modified/newer/older version of debcargo to generate source package contents though. If it just ended up there because someone misunderstood where/how debcargo is involved in building Rust packages maintained by the Rust team, it might be good to clarify and/or remove it from that list :) Furthermore, if the answer to #1084048 is that Trixie should ship with a Rust 1.85 toolchain to support the new edition, it would also be great if that also extends to rust-cargo and rust-debcargo, so that the version of debcargo shipping in Trixie can handle crates using that Rust edition, even if debcargo is otherwise covered by the early stages of freezing (e.g., we could do an upgrade just updating the used cargo library via an unblock request, without adding new features in debcargo itself). Another Rust team member brought up that bindgen (the Rust crate that allows semi-automatically generating Rust bindings to native/C libraries, used by most low-level foo-sys crates containing such bindings that higher level abstractions build upon) might be considered part of the Rust toolchain (it provides both a library in librust-bindgen-dev, and a CLI tool in bindgen, built from two separate source packages). There aren't too many reverse-build-dependencies on it, but deciding what makes the cut and what doesn't is your domain after all ;) The inverse (cbindgen, to generate C bindings for Rust code) also exists, but its usage is (even) less widespread. Thanks for your consideration! > We are happy to receive your feedback - especially on the change > regarding d-i. The proposed text for the freeze policy can be found in > the following merge request on salsa: > > https://salsa.debian.org/release-team/release.debian.org/-/merge_requests/27 > > Best > Sebastian for the release team > > [1] https://release.debian.org/testing/essential-and-build-essential.txt > which we intend to extend with all llvm-toolchain versions that are > planned to be included in the trixie release. > -- > Sebastian Ramacher
