On Wed, 14 Jan 2026 at 18:09, James Addison <[email protected]> wrote: > > 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.
I think that I should research the release-selection mechanism in Salsa CI pipelines more before commenting further. Documentation for that feature can be found at: https://salsa.debian.org/salsa-ci-team/pipeline#distribution-and-release-selection Regards, James
