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 <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
