-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi all,

During the wonderful mini-DebConf at Cambridge, the Release Team had a sprint and other discussions. Some of the discussed topics are worth sharing, so here we go.


A future for the i386 architecture
==================================

Insofar as they still do, we anticipate that the kernel, d-i and images teams will cease to support i386 in the near future. Following that, there are two routes into running i386:

1. as a multi-arch option on an otherwise amd64 system
2. as an i386 chroot on another architecture system

We're not planning to make i386 a partial architecture in the way [1] Ubuntu has, arch:any will still contain i386 so everything builds by
default. Maintainers who wish to drop i386 support can do so *after* coordination with the reverse (build) dependencies of their package, as with dropping support for any other architecture. We also like to note that we have no opposition to changes to the baseline when these changes land (it's a port matter).


Reproducibility migration policy
================================

The folks from the Reproducibility Project have come a long way since they started working on it 10 years ago, and we believe it's time for the next step in Debian. Several weeks ago, we enabled a migration policy in our migration software that checks for regression in reproducibility. At this moment, that is presented as just for info, but we intend to change that to delays in the not so distant future. We eventually want all packages to be reproducible. To stimulate maintainers to make their packages reproducible now, we'll soon start to apply a bounty for reproducible builds, like we've done with passing autopkgtests for years. We'll reduce the bounty for successful autopkgtests at that moment in time.


Tier proposal rejected
======================

We discussed the Archive Tier proposal [2] by elbrus and came to the conclusion that there were too many difficulties with defining it well on the official archive side of things to make it useful and worthwhile. While elbrus will no longer pursue the proposal, we think the ports side of the story has value even without having the official archive part of the proposal.


State of the team
=================

We covered several domains of how the team works. One thing we recognized is that there are multiple areas of responsibility and that not every area is (nor needs to be) covered by every team member. However, that's implicit and has put a mental burden on the team members. We intend to make it explicit who feels primarily responsible for what, most likely with a WiKi page.

Another topic we covered is the volume and purpose of our mail list (debian-devel@lists.debian.org). We recognize that that list mostly just mirrors BTS traffic. The BTS already archives all information, and there are multiple ways anyone can subscribe to the Release Team bugs, so this mirroring seems unnecessary. More importantly it inhibits the list from being a more useful discussion channel that we like it to be. Hence, we'll try to work with the BTS maintainers to direct the traffic away (such that one can still subscribe to all bug traffic if one would want to in the regular ways) and at the same time inviting more generic Release Team related discussions to happen on the list. Please keep using the BTS for established workflows like (old-)stable-proposed-updates, unblock and transition requests.

Although that may not be obvious, we're always open for new team members. We have the ambition to document (again, on the WiKi) ways that interested people can engage with working with us. Everybody can help review transition and unblock requests and proposals for (old-)stable-proposed-updates updates, as long as they don't claim authority. Working and commenting on our open bugs is a great way to learn how we do the vast majority of our work, while at the same time showing that one (starts to) understands it.

On behalf of the Release Team,
Paul

[1] https://wiki.ubuntu.com/i386
[2] https://salsa.debian.org/elbrus/memos/-/blob/main/tier-proposal.md





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

iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmV96dcACgkQnFyZ6wW9 dQqPtgf+LaKyW7IXTWE3E3sdwNEObJssaY3nL98mvEzjtXzVTj8wik6BFGU33Zj8 vfI9D39GkZom1vPVmQcOb3L9IKLYE30SEciBCxLpx1/fDXDjPtYZAB5X645jytTy cwtf/zG38R8m/iR2aws0U/+O9OdCkZ2+B7B/sTx/0lfnj+jHiYQr1xvmPqUoVoOy rn+a264afycgv7nOSR4d7JYz8gXvkRxQSdxSteV3ySR3TpOXlEyjDWpzg12pLryj KSXulhON/ixDaREdMIWRlUGP/ahmNYpnHFcp6sOfDQRGwpQ56VEAxtqxY26oUxQ3 PFT56lBwWnXAoahJRyH2LkkDcInKsA==
=xTHs
-----END PGP SIGNATURE-----

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