Re: What are the most important projects that Debian ought to work on?
On Mon, 24 Jan 2022, Sébastien Delafond wrote:
> That's where you come into play: it would be nice if you could share
> what are — according to you — the most important projects/improvements
> that Debian ought to make. You can share your ideas here by replying to
> this email, but it would be interesting to file them as new issues in
> the "grow-your-ideas" project and then reply here pointing to your new
> issue:
I have filed https://salsa.debian.org/debian/grow-your-ideas/-/issues/21
which states:
Better infrastructure to manage transitions
# The problem
It's too much manual work to handle a big transition.
# Actual workflow
When you introduce a new major upstream version, you often have to handle
a transition because (many) other packages have to be updated to cope with
that new version. Ideally, you do a mass-rebuild of the reverse
dependencies (build- and runtime-dependencies) and you run their
autopkgtest to ensure that they are still working.
If you are a very good citizen, you might use `ratt` to do the rebuilds
and you might upload the package to experimental to figure out with
ci.debian.net if you break other packages. But more likely you don't know
about those, or you decide that you don't have the computer resources to
run those, and you do nothing (except possibly filing bugs or sending
mails to ask other maintainers to test their packages with your updated
package).
At some point, you upload your package because you decided that you left
enough time for others to fix their packages and you end up breaking their
packages... at least the bug will be raised to release critical and the
package will either be fixed or removed, which should eventually allow
your package to migrate to testing.
# Expected workflow
1. You upload the new version as usual, dak detects that it's breaking
many packages and it thus decides to put the package in a dedicated
package repository (think PPA) that will be used to handle the transition.
2. The required-binNMU are triggered and the resulting binaries are
uploaded in the PPA.
3. The failing rebuilds appear in the dedicated transition tracker.
4. The failing autopkgtest appear in the dedicated transition tracker.
5. You click on a button to submit all the bug reports for the failing
rebuilds and failing autopkgtest. The corresponding bugs and their status
automatically show up in the transition tracker.
6. After a while, most of the bugs have been fixed and the transition
tracker is looking much better. The system did automatically test the
newest versions that were uploaded to unstable. The binNUM have been
updated as well for the packages that have been updated in parallel.
7. That said the number of broken packages is still too high for your
limited time, so you decide to ask for help to other team members.
Together you manage to review all the failures. Sometimes you provide a
fix and record the associated merge request in the system. Sometimes you
decide to ignore the issue because it's better to remove the package and
you add a note explaining this.
8. When you're done, the release team takes a look at your transition
tracker, and gives you the green light to go ahead, you finalize all the
uploads to the PPA for the packages that had a pending merge requests and
you click on a button that uploads all the packages from the PPA directly
to unstable.
9. All the packages migrate to testing in a few days.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: