<div dir="auto"><div>Hi Otto,</div><div dir="auto"><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Jan 14, 2026, 17:22 Otto Kekäläinen <<a href="mailto:otto@debian.org">otto@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
Seems Release Team members didn't have additional comments on this,<br>
perhaps as on a quick look very few of the Release Team members use<br>
Salsa CI to verify their own packages before upload.<br>
<br>
Even if you are not using or seeing value in Salsa CI, what are your<br>
opinions on having these two related rules for unstable -> testing<br>
migrations based on vcswatch data?<br>
<br>
1. If the package has Vcs-* field as a sign that it is using VCS (93%<br>
Salsa), but the uploaded packages has extra contents not pushed to<br>
VCS, delay the migration by 10 days. The uploader can easily notice<br>
they forgot to 'git push' and get the delay down by simply pushing<br>
their commits.<br>
<br>
2. Assuming the above - i.e. git contents is up-to-date and there is<br>
no 10 day delay because of that - if the vcswatch reports the CI<br>
status as 'failed', delay the migration by 10 days. This should<br>
incentivise packages using CI to actually ensure the CI passes before<br>
upload. The rule won't affect those not using CI, and packages that<br>
run CI but don't actually look at the results and they are always<br>
failing should be encouraged to disable the CI. This will free up<br>
resources to those who actually look at CI results before upload.<br>
<br>
<br>
> Does other Release Team members have any thoughts on potentially using<br>
> the existing vcswatch information for unstable -> testing transitions?<br>
><br>
> Repeating some suggestions I threw in my first email:<br>
><br>
> > The vcswatch tool is tracking the CI pipeline status on Salsa for all<br>
> > packages that have a Vcs-Git URL pointing to Salsa. There could be for<br>
> > example a rule that if a package is hosted on Salsa, and if the git<br>
> > repo is up-to-date with what was uploaded and CI is passing, the<br>
> > package could migrate faster from unstable->testing. Alternatively<br>
> > there could be a negative rule that adds extra delay to any package<br>
> > that is not in sync in git or has no CI or a failing CI. I guess one<br>
> > could also justify a ruleset where packages with no CI are considered<br>
> > neutral, but if there is a CI and it is failing, the package would get<br>
> > extra delay or not migrate from unstable to testing at all as there is<br>
> > something that provably regressed.<br>
><br>
> I will reply to Adrian's comments about Salsa CI usage later, but I<br>
> wanted to ask this first to get the discussion back on topic.<br>
<br>
-- <br>
Debian-salsa-ci mailing list<br>
<a href="mailto:Debian-salsa-ci@alioth-lists.debian.net" target="_blank" rel="noreferrer">Debian-salsa-ci@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-salsa-ci" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-salsa-ci</a></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 <a href="http://mentors.debian.net">mentors.debian.net</a> 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.</div><div dir="auto"><br></div><div dir="auto">Are there ways to manage that as a packager?  If so, I'll begin experimenting with those in my ITP package.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">James</div><div dir="auto"></div></div>