Re: Updates to the trixie freeze policy

Hi,

Sebastian Ramacher <[email protected]> (2024-11-02):
> 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.

It looks to me “how to avoid burning out coworkers” didn't make it into
“lessons learnt”.

> During the bookworm release we made the following observations:
[…]
> * the work on d-i and images takes time and requires a non-moving set
>   of packages to work on

The last part is not true, and has never been true in the 12+ years I've
been involved.

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

It looks to me that's going to put more pressure on us, on me, in a
continuous fashion, during the entire freeze. It really looks like
you've entirely ignored what I wrote to the team about burnout.

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

That's always been the case. Thank you for not taking *that* away, I
guess?

> 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

My favorite course of action is *not* changing anything regarding d-i
(except the fingerpointing I received afterwards, that I really would
have loved to avoid).


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

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmcmcWAACgkQ/5FK8MKz
VSCjgxAAnGuYWdwdJZ1Sv1FAPyN1l3tNcja4ms1srblWi+YQUf6qBMtqcPmd8Rww
U3MnKHvQlWUGA3RPgAzhdRIkvq76I0P1MCgy8P1C4gUvgIUyuMWabLoU6oFaA0jR
HR4TRUkMWXQrfIy6B3igAAituvWP0mMMIdoX9jll2tu05yazkkCswLteO8R9sSOH
hVEZnPeRjGwhRz4ow73IA1DhHo2Dby99rqzZENnmkg36n/mvAzlpdMG7aOzmjLK2
IpuYngZOLR5X38dSjlHnv+rRnq3XKRB8bGDgM4J/miFj/3OL4Ca/hrMbScuHs/wq
tLGoW+JxPb9HEBjd0VQdjtz9z3KH9lKJJG9L+1OJdKTXWrSJcq0lDi+g0sMG5WW3
y66SlwD6a+eC6iSATswvYFySu4PAnu57P354rakE2g68ASRHXlFhn3oyPTkO6f36
K/CvzbcGO+lQh/bsKUFDpOMfJh8pGcvCw/PVaUnNdHmkH9ATaaurw3dnMrkfBwDk
wnP8UuuH19n/pbmsRlarxC5td149rKkbA9gEkdE1WQ9DXUWKwZ+TQJVKYxZYe6MH
JkQCeEBhXDtGJ/uuKO/ahUv+ecTFShZv010dHKIG83bCmZN9VNEGk/AosFA9XbuP
hH737qnUqEuJyhVND4w5516jOqREKhNWwyMcpIz5Ht7vmTI0V1s=
=/W1e
-----END PGP SIGNATURE-----