Hi,

Thanks for contacting maintainers impacted by the new timeline scheme.

On 2024-11-02 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.

During the bookworm release we made the following observations:
* 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.

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

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

--
Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[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)

On Sat, Nov 02, 2024 at 06:35:53PM +0100, Sebastian Ramacher wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Nov 02, 2024 at 06:35:53PM +0100, Sebastian Ramacher wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--9176def213b4034553984c9a0a994f661f53f04327722c165d7762eb3f3e Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Apologies if this is a dumb question ...

On Sat Nov 2, 2024 at 6:35 PM CET, Sebastian Ramacher wrote:

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 [email protected] 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

--9176def213b4034553984c9a0a994f661f53f04327722c165d7762eb3f3e
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZypw2wAKCRDXblvOeH7b bhq7AQDoSD7+gooGlUh89+yIDJUE8NgJCM8lufxGjsdjcl5QnAD/VRHfBlDuJRIX yyke4dezo4GZPkN8kCG8rgSmybXqRgU=QpPD
-----END PGP SIGNATURE-----

--9176def213b4034553984c9a0a994f661f53f04327722c165d7762eb3f3e--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot, linux.debian.maint.gtk.gnome

On Sat, 02 Nov 2024 at 18:35:53 +0100, Sebastian Ramacher wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot, linux.debian.maint.gtk.gnome

Simon McVittie <[email protected]> (2024-11-12):

On Sat, 02 Nov 2024 at 18:35:53 +0100, Sebastian Ramacher wrote:

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.

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

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

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.

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

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,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmc0GO0ACgkQ/5FK8MKz VSDoyg//fK7jLzQHzHkQAaHars4t2YNNdoxUs12ScnEWExxKEDSTxU4SFxKA8b7c MPpouY9gRPTH2wvQoKYgSi7ib/ysKnBCxBnP14vECtcoWtxTo8BvtsZXyC76idrK Q7IXxhFmLd/emYyUliVWl1qC14sicspkgefwf6HhiD6wQM2JURpvsuTHeMIjXhbK zWkFsXEEO1MF/kSvuloPu6t9vMtlczb6NF0pIGZE8B2d6Q6QYAuilniQF1lNHhLS ZdwWWXF5QEJsZpsjOSwvHF5xPzOzBEXFjg7D18/JrLN4L4hqByACbex/0mszIHGW ynPZG5gSWtOJqcVdLDtEH+OY8nsgp9u/cjrMf0pK7q61ShBlHer+X8ZWQzvtDTNv 15KJb8JscCBY+HFBNXnaWRaCFC4bhkpkhOan2mYddvfgSJzU74CHdnzE7CZx2xO8 /Cmsck1VzFb2TgaaNhDwZQ/rdcFQFQ1PkBU5vzb3/xUDx3Uz4F4U2h9E6RrXN3If DyNj2QUpBDyRgrbBFOhkwgOph9uv7tDHeXPmK1yPyL6io7t09M3kOw/U2DBNdNI0 AiIr6SXHg7RhgZTtq2Babxyke0JuWaT1YTFhenC6xi7j0N/EF6/RZCxnpSYiZcIk DvRicw++/YgPJzSP7mJHyPZo2/njteqqBa53+jp+Qah96qAl7bg=
=/oTa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot, linux.debian.kernel

Hi Sebastian,

[trimming bit recipents list + adding debian-kernel]

On Sat, Nov 02, 2024 at 06:35:53PM +0100, 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].

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)