Updates to the trixie freeze policy

[Aurelien Jarno]

Hi,

Thanks for contacting maintainers impacted by the new timeline scheme.

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.
* 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.
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

[Fabian Grünbichler]

[To trimmed, since this is probably only interesting to Rust and RT people]

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.
* 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.
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
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

[Adrian Bunk]

...
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].
...
Milestone 2 (Milestone 1 + 2 months): Transition freeze
At this point we stop starting transitions.
...

Under these rules, everything frozen in Milestone 1 might still be part
of transitions.

Like rustc requiring updating as part of a libgit2 transition.

And a clear lesson from the bookworm freeze should be that a freeze
must not start with an unfinished Python3 transition.

For the transition part I would suggest:

Milestone 1: All transitions of key packages must be finished before
this milestone

Sebastian Ramacher

cu
Adrian

[Diederik de Haas]

Apologies if this is a dumb question ...

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.

In the (original) addressee list I didn't see debian-***@l.d.o but
the kernel produces several udebs as well. So shouldn't they be included
as well?

The list of packages that is involved can be found at [1].
[1] https://release.debian.org/testing/essential-and-build-essential.txt

libgcc-12-dev seems a bit odd? gcc-defaults is at 14 and that's
(currently) also the version used by the kernel.
And ``apt-cache rdepends libgcc-12-dev`` didn't make it clear why that
version should be included as well. At least to me.

Cheers,
Diederik

[Adrian Bunk]

...
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.
...

I'd suggest to add a step scheduling binNMUs in unstable for all
packages in testing at this point.[1]

It handles missing rebuilds for PIE or PAC/BTI or anything similar
automatically.

Binaries built a decade ago might no longer build on all architectures,
or even worse they might everywhere build but lose functionality.

An example would be that -Werror=implicit-function-declaration now being
the default has resulted in a not so small amount of wrong test failures
in autoconf scripts. If a package was not rebuilt in recent months and
the failure does not cause a FTBFS, our users might only notice when a
DSA results in a rebuild of the package that this disabled some
functionality they use.

64-bit time_t changes might also cause incompatible runtime changes,
like for example:
https://github.com/oetiker/rrdtool-1.x/issues/1264#issuecomment-2312626927

I am under no illusion that all issues would be reported (or even fixed)
before the release, but everything that might break should be broken
when people expect breakages when upgrading to trixie - and not suddenly
show up in a DSA or point release update that might even be installed
automatically.

Sebastian Ramacher

cu
Adrian

[1] Not scheduling binNMUs for packages that will miss trixie will avoid
some build time on various gcc/openjdk/llvm/... versions.

[Simon McVittie]

In trixie we will also freeze all packages that produce udebs

Is it straightforward to give packages whose udebs are not yet in active
use a semi-automatic exemption from this freeze, while still applying
other reasons they might be frozen?

I'm thinking mainly of src:gtk+3.0, src:vte2.91 and src:gtk4 here.
We added udebs to those packages a while ago, but they aren't in active
use because the graphical installer is still on GTK 2.

I don't fully understand the hint language, but would a permanent
"unblock-udeb gtk+3.0", etc. for each of the affected packages perhaps
have the desired effect?

I think src:dbus and maybe some of the AT-SPI stack are in a similar
situation: they added udebs a while ago, to unblock the ability to add
accessibility technologies to the graphical installer, but as far as I'm
aware they are not in active use.

I've seen suggestions that the GNOME team should be actively removing the
udebs from gtk+3.0, etc. to take it out of the udeb freeze set, but that
would require going back through NEW (with the associated delays) when
udebs are wanted again, and I'm not sure that's desirable.

Regarding the GTK 2 installer, I have been slowly learning how to test
cdebconf and refactoring it to use a more GTK-3-friendly threading
model, but I can't make any guarantees about when that will be ready for
review/merge or wider testing, and I certainly don't think it will be
production-ready by the end of the calendar year; "early forky cycle"
is probably a more realistic target for a GTK 3 installer.

smcv

[Cyril Brulebois]

Post by Simon McVittie

In trixie we will also freeze all packages that produce udebs

Is it straightforward to give packages whose udebs are not yet in
active use a semi-automatic exemption from this freeze, while still
applying other reasons they might be frozen?

That should be the case.

Post by Simon McVittie
I'm thinking mainly of src:gtk+3.0, src:vte2.91 and src:gtk4 here. We
added udebs to those packages a while ago, but they aren't in active
use because the graphical installer is still on GTK 2.

TL;DR: Yes to everything you're proposing.

I don't think they've been caught up in the temporary freezes (I'd think
the longest one last cycle was a little week, usually a few days,
sometimes just a few hours), so I've never taken the time to adjust (1)
the hints and (2) the tooling that makes sure the relevant hint files
knows about all udebs. That could be done if we were to have a permanent
udeb freeze (I'm not advocating for that).

Post by Simon McVittie
I don't fully understand the hint language, but would a permanent
"unblock-udeb gtk+3.0", etc. for each of the affected packages perhaps
have the desired effect?

Not having a block-udeb gtk3.0 in the first place would be slightly more
straightforward (see https://release.debian.org/britney/hints/freeze
which is usually mostly skipped because of the “finished” near the top,
until I get rid of that line to implement temporary freezes for udebs).

Post by Simon McVittie
I think src:dbus and maybe some of the AT-SPI stack are in a similar
situation: they added udebs a while ago, to unblock the ability to add
accessibility technologies to the graphical installer, but as far as
I'm aware they are not in active use.

That'd require double-checking, but if that's indeed the case and nobody
picked them up while we weren't looking, sure.

Post by Simon McVittie
I've seen suggestions that the GNOME team should be actively removing
the udebs from gtk+3.0, etc. to take it out of the udeb freeze set,
but that would require going back through NEW (with the associated
delays) when udebs are wanted again, and I'm not sure that's
desirable.

Getting you to undo/redo things looks like a waste of your time and
ftp-master's. Adjusting hints (and hint-side tooling) seems like the
obvious way to go (again, not done until now because that didn't seem
required).

We would also lose installability checks, see:
https://d-i.debian.org/dose/

There we see that a bunch of packages are not installable in unstable,
including at-spi2-core-udeb (via libsystemd0), libvte-2.91-0-udeb and
libgtk-3-0-udeb (via libxcomposite1).

Post by Simon McVittie
Regarding the GTK 2 installer, I have been slowly learning how to test
cdebconf and refactoring it to use a more GTK-3-friendly threading
model, but I can't make any guarantees about when that will be ready
for review/merge or wider testing, and I certainly don't think it will
be production-ready by the end of the calendar year; "early forky
cycle" is probably a more realistic target for a GTK 3 installer.

At this point, unless it was ready like right now, the next cycle seems
much better indeed.

And many thanks for looking into that.


Cheers,

[Andreas Tille]

Post by Cyril Brulebois
I don't think they've been caught up in the temporary freezes (I'd think
the longest one last cycle was a little week, usually a few days,
sometimes just a few hours), so I've never taken the time to adjust (1)
the hints and (2) the tooling that makes sure the relevant hint files
knows about all udebs. That could be done if we were to have a permanent
udeb freeze (I'm not advocating for that).

I admit I’m not very familiar with the release process. However, my
(possibly flawed) memory recalls that we used to have some kind of d-i
alpha for very early testing, available even before the freeze. Could
you confirm this, or am I misremembering?

Additionally, I wonder if an automated test suite for the installer
might be helpful. In my admittedly naive view, something like
Babelbox[1] could serve this purpose. I remember we used it at some
Linux events at the Debian booth to demonstrate how easily Debian can be
installed. Could you share your thoughts on this?

Kind regards
Andreas.

PS: Please CC me, I'm not subscribed to these lists.

[1] https://wiki.debian.org/DebianInstaller/BabelBox

[Cyril Brulebois]

Post by Cyril Brulebois
I don't think they've been caught up in the temporary freezes (I'd
think the longest one last cycle was a little week, usually a few
days, sometimes just a few hours), so I've never taken the time to
adjust (1) the hints and (2) the tooling that makes sure the
relevant hint files knows about all udebs. That could be done if we
were to have a permanent udeb freeze (I'm not advocating for that).

I admit I’m not very familiar with the release process. However, my
(possibly flawed) memory recalls that we used to have some kind of d-i
alpha for very early testing, available even before the freeze. Could
you confirm this, or am I misremembering?

Yes, and that's what would have happened this release cycle again if I
hadn't been totally burned out (see my first reply to this thread).

Additionally, I wonder if an automated test suite for the installer
might be helpful. In my admittedly naive view, something like
Babelbox[1] could serve this purpose. I remember we used it at some
Linux events at the Debian booth to demonstrate how easily Debian can
be installed. Could you share your thoughts on this?

We have various kinds of automated testing.

In my understanding, Babelbox was about showcasing language support.
That's some heavily scripted installation though (≠ not how most users
are interacting with the installer).

All that is quite orthogonal to what you're replying to anyway.


Cheers,

[Salvatore Bonaccorso]

Hi Sebastian,

[trimming bit recipents list + adding debian-kernel]

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.
* 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.
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].
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.

How would you aim or envision the role of src:linux in this picture?
In past we still did the stable release rebases in unstable, beeing
more careful and in ocordination still with release team and d-i
folks, but this allowed to keep the pace on upstream stable versions
with bugfixes.

Do you still see this a posiblity for the coordination work between
release team, d-i, debian-boot and kernel updates?

Regards,
Salvatore