On 02.11.24 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.
Looking back at the bookworm milestones, I'm aware that the Milestone 1
could be away less than two months. What kind of planning do you expect
from these affected maintainers with such short notices? I have to
assume here similar dates as for the past cycle, as there are still no
dates communicated.
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
is there a public view on what lessons were learned from the previous
release cycle? Or are these just these two items from above? If not,
then I'd like to list at least to keep the toolchain freezes limited for
new upstream versions, and still allow packages being updated from
maintenance branches.
Python:
I am also unhappy that no actual proposal for freeze dates are given at
this point of time. This doesn't allow any useful planning for getting
ready for the release with specific upstream versions. Talking here
about the Python 3.13 migration, and the issues we had during the
bookworm freeze. I had been asking about a later freeze for that, but
looking back at emails, I don't see any feedback on that from the
release team. So just based on personal and private conversations, we
will go ahead with plan to ship trixie with Python 3.13 as the default,
and assuming later freeze dates than we had for bookworm. But it would
be nice if this communication could be more public for future releases.
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.
LLVM:
You're talking about "maintainers of packages not contained in the build
essential / toolchain set", but seem to assume that time resources of
maintainers of toolchain packages are not affected. Especially for
LLVM, introduction of new LLVM versions for testing had been actively
hindered by the release team, and despite one release team member being
present on #debian-llvm, feedback on this channel and on RC issues has
been scarce during the trixie development cycle. There's nothing which
can be changed now for this release cycle, but that is definitely
something which should be changed for the next cycle. Not allowing new
LLVM versions into testing is counter-productive for adoption.
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].
this should be freeze for major upstream versions, keeping the
toolchains open to updates from maintenance branches.
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.
Milestone 2 (Milestone 1 + 2 months): Transition freeze
At this point we stop starting transitions.
Milestone 3 (Milestone 2 + 1 month): Soft freeze
As with bookworm, with the soft freeze only small and targeted fixed are
appropriate. Also, packages not in testing are blocked from migration to
testing.
this is the milestone I would like to see see the final toolchain freeze.
Milestone 4 (Milestone 3 + 1 month): Hard freeze
Key packages and packages without autopkgtest will be treated as in the
full freeze and require manual review by the release team.
Milestone 5 (Milestone 4 + ? months): Full freeze
This is the last phase of the release where all packages require manual
review by the release team. Updates that are allowed to migrate to
testing are reduced to: targeted RC bug fixes, targeted bug fixes for
important bugs if done via unstable, translation and documentation
updates if done via unstable, updates of packages relevant for the
release process.
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.
