Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Bits from the Release Team: Cambridge sprint update

Skip to first unread message

Paul Gevers

Dec 16, 2023, 1:30:04 PM12/16/23
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

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
( 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,



0 new messages