[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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)