On Sat, Jan 03, 2026 at 10:00:16PM -0800, Otto Kekäläinen wrote: > Hi!
Hi Otto! > 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? I am not a member of the Release Team, but I wonder what information you have in mind that is not already being available and used by the britney CI? > 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? AFAIK your "on all Debian packages" is factually incorrect, with resource limits in the Salsa CI preventing the build of many packages. Being able to build every single package in main in the Salsa CI would be a prerequisite for what you want below. > 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. If something has provably regressed, this should already block testing migration due to failing also in the britney CI. > 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. If the britney CI is also green, the maintainer is already being rewarded by migration of the package to testing. In the current setup the britney CI is the one that matters, and the Salsa CI is simpler testing the maintainer can use for finding some kinds of issues already before the upload. Trying to make running full CI in more than one place in different environments mandatory would create additional work and frustration for many maintainers without providing real benefits. Long-term it would IMHO be good to have one CI at the git hosting and nothing else, but that's distant future and having two mandatory CIs at any time would be bad. Your attempt to use the Release Team as a stick to force maintainers to use the Salsa CI gives the impression that something is wrong with the Salsa CI that makes maintainers not want to use it. What problems with the Salsa CI prevent maintainers from using it? Not being able to build all packages is a problem, and there might be other issues where maintainers might appreciate improvements. How can the Salsa CI make life easier so that more maintainers want to use it? A maintainer task relevant to the Release Team not currently covered by our infrastructure are test rebuilds for transitions. Providing this as an optional step in the Salsa CI would be very useful for maintainers. > - Otto cu Adrian
