Hi Otto, On Wed, Jan 14, 2026, 17:22 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. > > -- > Debian-salsa-ci mailing list > [email protected] > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-salsa-ci I'm not in the release team, but I did notice during some recent work with Salsa CI that the versions of various components used by the pipeline -- lintian, to take one example -- may differ from other package release environments. I'm uploading to mentors.debian.net which I admit is not the official archive -- but even so I could imagine it could be difficult to upload packages that always pass CI in both Salsa and elsewhere. Are there ways to manage that as a packager? If so, I'll begin experimenting with those in my ITP package. Thanks, James
