Re: Updates to the trixie freeze policy
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.
Reply to: