Hi Debian Release Team, I am resurrecting this proposal for using the Salsa CI status in unstable->testing migration.
Specifically I'd like to float the idea that IF a project uses Salsa CI, AND IF the Salsa CI was failing (red) for the git tag corresponding to the upload (vcswatcher already has this data), the migration would be delayed by 10 days. This would encourage those who use Salsa CI to actually make sure it passes _before_ uploading. Currently packages can have a failing CI and nothing stops them from uploading. For example today I saw package 'rtpengine' failing in autopackagetest at https://ci.debian.net/packages/r/rtpengine/testing/amd64/71831181/ with error: Error! Build of xt_RTPENGINE.ko failed for: 7.0.10+deb14-amd64 (x86_64) Without quoting the full context, the exact same error was already visible in the autopkgtest on Salsa CI for the commit that was tagged as the upload in https://salsa.debian.org/pkg-voip-team/rtpengine/-/jobs/9706325: E: rtpengine/26.0.1.13 failed to build for 7.0.10+deb14-rt-amd64 Looking at the history of CI at https://salsa.debian.org/pkg-voip-team/rtpengine/-/commits/master I see that Salsa CI is totally being ignored. It would be better for that package to just turn off CI and not waste machine and human resources on trying to maintain it if the package maintainer can just totally ignore the result. If we had a holistic end-to-end git-based CI system uploads of a failed commit would not be possible. The next best thing would be to simply penalize them in the unstable to testing migrations. I would like to hear the views official release team members - does this rule suggestion resonate with you? - Otto On Thu, 15 Jan 2026 at 01:21, Otto Kekäläinen <[email protected]> wrote: > > Hi! > > Seems Release Team members didn't have additional comments on this, > perhaps as on a quick look very few of the Release Team members use > Salsa CI to verify their own packages before upload. > > Even if you are not using or seeing value in Salsa CI, what are your > opinions on having these two related rules for unstable -> testing > migrations based on vcswatch data? > > 1. If the package has Vcs-* field as a sign that it is using VCS (93% > Salsa), but the uploaded packages has extra contents not pushed to > VCS, delay the migration by 10 days. The uploader can easily notice > they forgot to 'git push' and get the delay down by simply pushing > their commits. > > 2. Assuming the above - i.e. git contents is up-to-date and there is > no 10 day delay because of that - if the vcswatch reports the CI > status as 'failed', delay the migration by 10 days. This should > incentivise packages using CI to actually ensure the CI passes before > upload. The rule won't affect those not using CI, and packages that > run CI but don't actually look at the results and they are always > failing should be encouraged to disable the CI. This will free up > resources to those who actually look at CI results before upload. > > > > Does other Release Team members have any thoughts on potentially using > > the existing vcswatch information for unstable -> testing transitions? > > > > Repeating some suggestions I threw in my first email: > > > > > 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 will reply to Adrian's comments about Salsa CI usage later, but I > > wanted to ask this first to get the discussion back on topic.
