[Debian-salsa-ci] Release team to utilize Salsa CI for Forky quality assurance?

[James Addison]

Hi Otto,

On Wed, Jan 14, 2026, 17:22 Otto Kekäläinen <otto at debian.org> 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
> Debian-salsa-ci at alioth-lists.debian.net
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-salsa-ci/attachments/20260114/3e8cebce/attachment.htm>