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

[James Addison]

On Wed, 14 Jan 2026 at 18:09, James Addison <jay at jp-hosting.net> wrote:
>
> 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.

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