[DRE-maint] Updates to the trixie freeze policy

[Matthias Klose]

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.