Hi! As releasing a new Debian version involves a great deal of effort in avoiding regressions and keeping package quality high, I imagine the Release Team's interests are very much aligned with what Salsa CI does.
Thus I wanted to ask if the Release Team has had any internal discussions on how to better utilize Salsa CI for ensuring Forky has minimal amount of regressions? Are there any new quality assurance tools you would like the Salsa CI pipeline to run by default on all Debian packages in an effort to prompt maintainers to ensure those tests pass? Are there any plans to incorporate the Salsa CI status in unstable -> testing migrations? The vcswatch tool is tracking the CI pipeline status on Salsa for all packages that have a Vcs-Git URL pointing to Salsa. There could be for example a rule that if a package is hosted on Salsa, and if the git repo is up-to-date with what was uploaded and CI is passing, the package could migrate faster from unstable->testing. Alternatively there could be a negative rule that adds extra delay to any package that is not in sync in git or has no CI or a failing CI. I guess one could also justify a ruleset where packages with no CI are considered neutral, but if there is a CI and it is failing, the package would get extra delay or not migrate from unstable to testing at all as there is something that provably regressed. I don't have a strong opinion on what the rules should be, just throwing out ideas above to start a discussion. I do however feel that the Release Team should in *some* way reward packages and maintainers who diligently keep CI green and quality high to foster a culture that testing, reading test results and proactively caring about quality is valued. - Otto
