[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi Otto,

On Wed, Jan 14, 2026, 17:22 Otto Kekäläinen <otto@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@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

Reply to: