Hi, as you seem to ignore mails by RT members, let me repeat my concerns once again.
On 2026-06-07 22:56:40 +0800, Otto Kekäläinen wrote: > 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. Britney is concerned with what is in the archive. Salsa is not the archive. It also has a questionable benefit if the Salsa CI per default runs autopkgtests (which we already have covered), runs piuparts (which we already have covered), runs blhc (which is unmaintained). Cheers > 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. > -- Sebastian Ramacher
