From otto at debian.org  Sun Jun  7 15:56:40 2026
From: otto at debian.org (=?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=)
Date: Sun, 7 Jun 2026 22:56:40 +0800
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
Message-ID: <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>

Hi Debian Release Team,

I am resurrecting this proposal for using the Salsa CI status in
unstable->testing migration.

Specifically I'd like to float the idea that IF a project uses Salsa
CI, AND IF the Salsa CI was failing (red) for the git tag
corresponding to the upload (vcswatcher already has this data), the
migration would be delayed by 10 days.

This would encourage those who use Salsa CI to actually make sure it
passes _before_ uploading. Currently packages can have a failing CI
and nothing stops them from uploading. For example today I saw package
'rtpengine' failing in autopackagetest at
https://ci.debian.net/packages/r/rtpengine/testing/amd64/71831181/
with error:

    Error! Build of xt_RTPENGINE.ko failed for: 7.0.10+deb14-amd64 (x86_64)

Without quoting the full context, the exact same error was already
visible in the autopkgtest on Salsa CI for the commit that was tagged
as the upload in
https://salsa.debian.org/pkg-voip-team/rtpengine/-/jobs/9706325:

    E: rtpengine/26.0.1.13 failed to build for 7.0.10+deb14-rt-amd64

Looking at the history of CI at
https://salsa.debian.org/pkg-voip-team/rtpengine/-/commits/master I
see that Salsa CI is totally being ignored. It would be better for
that package to just turn off CI and not waste machine and human
resources on trying to maintain it if the package maintainer can just
totally ignore the result.

If we had a holistic end-to-end git-based CI system uploads of a
failed commit would not be possible. The next best thing would be to
simply penalize them in the unstable to testing migrations.

I would like to hear the views official release team members - does
this rule suggestion resonate with you?


- Otto


On Thu, 15 Jan 2026 at 01:21, 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.


From sramacher at debian.org  Sun Jun  7 17:08:37 2026
From: sramacher at debian.org (Sebastian Ramacher)
Date: Sun, 7 Jun 2026 18:08:37 +0200
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
Message-ID: <aiWXhdSPbhHBxBqi@ramacher.at>

Hi,

as you seem to ignore mails by RT members, let me repeat my concerns
once again.

On 2026-06-07 22:56:40 +0800, Otto Kek?l?inen wrote:
> Hi Debian Release Team,
> 
> I am resurrecting this proposal for using the Salsa CI status in
> unstable->testing migration.
> 
> Specifically I'd like to float the idea that IF a project uses Salsa
> CI, AND IF the Salsa CI was failing (red) for the git tag
> corresponding to the upload (vcswatcher already has this data), the
> migration would be delayed by 10 days.

Britney is concerned with what is in the archive. Salsa is not the
archive. It also has a questionable benefit if the Salsa CI per default
runs autopkgtests (which we already have covered), runs piuparts (which
we already have covered), runs blhc (which is unmaintained).

Cheers

> This would encourage those who use Salsa CI to actually make sure it
> passes _before_ uploading. Currently packages can have a failing CI
> and nothing stops them from uploading. For example today I saw package
> 'rtpengine' failing in autopackagetest at
> https://ci.debian.net/packages/r/rtpengine/testing/amd64/71831181/
> with error:
> 
>     Error! Build of xt_RTPENGINE.ko failed for: 7.0.10+deb14-amd64 (x86_64)
> 
> Without quoting the full context, the exact same error was already
> visible in the autopkgtest on Salsa CI for the commit that was tagged
> as the upload in
> https://salsa.debian.org/pkg-voip-team/rtpengine/-/jobs/9706325:
> 
>     E: rtpengine/26.0.1.13 failed to build for 7.0.10+deb14-rt-amd64
> 
> Looking at the history of CI at
> https://salsa.debian.org/pkg-voip-team/rtpengine/-/commits/master I
> see that Salsa CI is totally being ignored. It would be better for
> that package to just turn off CI and not waste machine and human
> resources on trying to maintain it if the package maintainer can just
> totally ignore the result.
> 
> If we had a holistic end-to-end git-based CI system uploads of a
> failed commit would not be possible. The next best thing would be to
> simply penalize them in the unstable to testing migrations.
> 
> I would like to hear the views official release team members - does
> this rule suggestion resonate with you?
> 
> 
> - Otto
> 
> 
> On Thu, 15 Jan 2026 at 01:21, 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.
> 

-- 
Sebastian Ramacher


From andrea at pappacoda.it  Sun Jun  7 17:01:21 2026
From: andrea at pappacoda.it (Andrea Pappacoda)
Date: Sun, 07 Jun 2026 18:01:21 +0200
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
Message-ID: <DJ2XYIEAZY5J.3OYFFZJDMLNMY@pappacoda.it>

Hi all,

On Sun Jun 7, 2026 at 4:56 PM CEST, Otto Kek?l?inen wrote:
> Hi Debian Release Team,
>
> I am resurrecting this proposal for using the Salsa CI status in
> unstable->testing migration.
>
> Specifically I'd like to float the idea that IF a project uses Salsa
> CI, AND IF the Salsa CI was failing (red) for the git tag
> corresponding to the upload (vcswatcher already has this data), the
> migration would be delayed by 10 days.

This in principle would be very good. Still, I feel Salsa CI is still 
not reliable enough for these kinds of penalties.

One third of my packages report a failure in the VCS column of my DDPO 
page, to failures related to either Salsa CI or Salsa itself. For some 
of these, the failures are not transient and are caused by limitations 
of Salsa CI, and I don't bother with checking them anymore since they 
are so frequent.

https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/371

I hope that things will get better soon! I'm not motivated enough to fix 
them myself as I configured my local sbuild to run lintian and 
autopkgtests after build, and paired with git-debpush it gives me 
a somewhat high confidence of the quality of my uploads. Still, better 
CI would be a plus :)

Bye!


From otto at debian.org  Sun Jun  7 17:29:17 2026
From: otto at debian.org (=?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=)
Date: Mon, 8 Jun 2026 00:29:17 +0800
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <aiWXhdSPbhHBxBqi@ramacher.at>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
Message-ID: <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>

Hi,

> as you seem to ignore mails by RT members, let me repeat my concerns
> once again.

I am not ignoring any emails. It's just that many replies jump to
discussing individual Salsa CI jobs or individual packages using them
and not about the purpose of a CI or what it means to pass or fail.

...
> > Specifically I'd like to float the idea that IF a project uses Salsa
> > CI, AND IF the Salsa CI was failing (red) for the git tag
> > corresponding to the upload (vcswatcher already has this data), the
> > migration would be delayed by 10 days.
>
> Britney is concerned with what is in the archive. Salsa is not the
> archive. It also has a questionable benefit if the Salsa CI per default
> runs autopkgtests (which we already have covered), runs piuparts (which
> we already have covered), runs blhc (which is unmaintained).

Personally all my packages are green on Salsa CI before I upload them,
and my error rate on the actual ci.debian.net is very low. I just
referenced an example where an autopkgtest on Salsa CI that then
occurred on ci.debian.net and is now blocking other packages instead
of remaining an isolated case for the individual package that needs
more work before being uploaded. You are now just dismissing that the
autopkgtest in Salsa CI is useless.

If you think Salsa CI is useless, why don't you then suggest people
stop using it?

If you read my suggestion and think about it a bit more instead of
just jumping to dismiss it and discussing individual jobs, you
hopefully realize that if implemented it would make some
maintainers/packages disable Salsa CI, which would improve the
situation for everyone as there would be less useless/wasteful Salsa
CI use going on.


From sramacher at debian.org  Sun Jun  7 19:33:00 2026
From: sramacher at debian.org (Sebastian Ramacher)
Date: Sun, 7 Jun 2026 20:33:00 +0200
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
Message-ID: <aiW5XKsplsYy5XUG@ramacher.at>

On 2026-06-08 00:29:17 +0800, Otto Kek?l?inen wrote:
> Hi,
> 
> > as you seem to ignore mails by RT members, let me repeat my concerns
> > once again.
> 
> I am not ignoring any emails. It's just that many replies jump to
> discussing individual Salsa CI jobs or individual packages using them
> and not about the purpose of a CI or what it means to pass or fail.
> 
> ...
> > > Specifically I'd like to float the idea that IF a project uses Salsa
> > > CI, AND IF the Salsa CI was failing (red) for the git tag
> > > corresponding to the upload (vcswatcher already has this data), the
> > > migration would be delayed by 10 days.
> >
> > Britney is concerned with what is in the archive. Salsa is not the
> > archive. It also has a questionable benefit if the Salsa CI per default
> > runs autopkgtests (which we already have covered), runs piuparts (which
> > we already have covered), runs blhc (which is unmaintained).
> 
> Personally all my packages are green on Salsa CI before I upload them,
> and my error rate on the actual ci.debian.net is very low. I just
> referenced an example where an autopkgtest on Salsa CI that then
> occurred on ci.debian.net and is now blocking other packages instead
> of remaining an isolated case for the individual package that needs
> more work before being uploaded. You are now just dismissing that the
> autopkgtest in Salsa CI is useless.
> 
> If you think Salsa CI is useless, why don't you then suggest people
> stop using it?

For the purpose of unstable -> testing migration because we
have ci.debian.net that runs autopkgtests for packages in the archive
(with more architectures than Salsa CI supports). We already have this
information from other sources. So for this purpose I
have not seen a benefit from your proposal.

I am not saying that Salsa CI is useless for developers when preparing
updates. Whatever tools they use to perform high quality uploads is an
improvment. But that doesn't mean that these tools are a good source for
judging if a package in the archive is ready to migrate to testing.

Cheers
-- 
Sebastian Ramacher


From otto at debian.org  Thu Jun 11 06:10:35 2026
From: otto at debian.org (=?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=)
Date: Thu, 11 Jun 2026 13:10:35 +0800
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <aiW5XKsplsYy5XUG@ramacher.at>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
Message-ID: <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>

Hi,

...
> I am not saying that Salsa CI is useless for developers when preparing
> updates. Whatever tools they use to perform high quality uploads is an
> improvment. But that doesn't mean that these tools are a good source for
> judging if a package in the archive is ready to migrate to testing.

Again you are purely thinking about individual tests. I wonder if
other Release Team members see the forest for the trees?

The Release Team is Debian's main guardian of quality. Do you want to
reward the diligent people who test their packages continuously or at
least once before uploading to unstable, or do you want to maintain a
culture where unstable is a playground where anything goes, forcing
diligent people to just suck it up and clean up after others?

I've seen that the majority of the Release Team members do not use
Salsa CI on their own packages and don't want to promote it. However,
you could at least enforce a rule that *if* Salsa CI shows a package
is broken it should not be ignored and uploaded anyway, preventing the
brokenness from spreading from one package to affect multiple ones in
Debian unstable.


From bunk at debian.org  Thu Jun 11 07:14:01 2026
From: bunk at debian.org (Adrian Bunk)
Date: Thu, 11 Jun 2026 09:14:01 +0300
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
Message-ID: <aipSKbQGy587OCvU@localhost>

On Thu, Jun 11, 2026 at 01:10:35PM +0800, Otto Kek?l?inen wrote:
>...
> I've seen that the majority of the Release Team members do not use
> Salsa CI on their own packages and don't want to promote it. However,
> you could at least enforce a rule that *if* Salsa CI shows a package
> is broken it should not be ignored and uploaded anyway, preventing the
> brokenness from spreading from one package to affect multiple ones in
> Debian unstable.

This is not something the Release Team can do, you have to discuss with 
the Archive Operations Team if you want to block uploads to unstable.

When the package is broken then debci already catches it and prevents 
testing migration, adding salsa results to britney brings no benefits.

cu
Adrian


From otto at debian.org  Thu Jun 11 12:30:18 2026
From: otto at debian.org (=?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=)
Date: Thu, 11 Jun 2026 19:30:18 +0800
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <aipSKbQGy587OCvU@localhost>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
 <aipSKbQGy587OCvU@localhost>
Message-ID: <CAOU6tADWXsiAWdWJ8gBMs-=gBcsZKFpxsRDg8qcOw54-1h+daw@mail.gmail.com>

Hi,

> When the package is broken then debci already catches it and prevents
> testing migration, adding salsa results to britney brings no benefits.

Of course there is no direct benefit if you only consider the trees,
but the forest will likely flourish more. It seems I'm not getting my
idea across. All replies focus on individual checks or testing
mechanics..


From elbrus at debian.org  Thu Jun 11 13:49:27 2026
From: elbrus at debian.org (Paul Gevers)
Date: Thu, 11 Jun 2026 14:49:27 +0200
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
Message-ID: <13247851-9e5a-45c6-8015-8383c2eadb2c@debian.org>

Hi Otto

On 6/11/26 07:10, Otto Kek?l?inen wrote:
> Again you are purely thinking about individual tests. I wonder if
> other Release Team members see the forest for the trees?


You're pulling a dead horse. We (plural) said "no" on multiple occasions 
now when you asked about checking salsa ci status. If you don't 
understand our reasoning, maybe you should just accept the "no". You can 
of course also start a GR to overrule us (as this is a decision by 
delegates).

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-salsa-ci/attachments/20260611/59b3e1b1/attachment.sig>

From bunk at debian.org  Thu Jun 11 14:05:04 2026
From: bunk at debian.org (Adrian Bunk)
Date: Thu, 11 Jun 2026 16:05:04 +0300
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tADWXsiAWdWJ8gBMs-=gBcsZKFpxsRDg8qcOw54-1h+daw@mail.gmail.com>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
 <aipSKbQGy587OCvU@localhost>
 <CAOU6tADWXsiAWdWJ8gBMs-=gBcsZKFpxsRDg8qcOw54-1h+daw@mail.gmail.com>
Message-ID: <aiqygAMj0p3ebEhI@localhost>

On Thu, Jun 11, 2026 at 07:30:18PM +0800, Otto Kek?l?inen wrote:
> Hi,

Hi Otto,

> > When the package is broken then debci already catches it and prevents
> > testing migration, adding salsa results to britney brings no benefits.
> 
> Of course there is no direct benefit if you only consider the trees,
> but the forest will likely flourish more. It seems I'm not getting my
> idea across. All replies focus on individual checks or testing
> mechanics..

a flourishing jungle of different CIs running basically the same tests 
in slightly different environments is not a good idea, for packages
with fragile tests it can be outright harmful.

The ideal number of CIs is one, more is worse.

Trying to push maintainers to use more than one CI is bad,
this is often a waste of not only resources but also precious
maintainer time.

Whatever the maintainer does in salsa is up to the maintainer,
if the maintainer considers the Salsa CI useful because it runs
at every commit then that's good for the maintainer.

unstable is as its name implies.
The CI to keep broken packages out of testing is already blocking
testing migration.

A FTBFS or autopkgtest failure in unstable is not a big deal if the 
maintainer handles it, and the one CI where maintainers should really
check the results is britney.

cu
Adrian


From otto at debian.org  Thu Jun 11 16:13:37 2026
From: otto at debian.org (=?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=)
Date: Thu, 11 Jun 2026 23:13:37 +0800
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <aiqygAMj0p3ebEhI@localhost>
References: <CAOU6tADruNc4E_4_FGtXiY5LkJK6eeTNfGiH-2BLkHNOg3c5Yw@mail.gmail.com>
 <CAOU6tACC4fjtU8VPpRTrj7KYZt5ePe0gcT1f9fCnrrC0OoQvxQ@mail.gmail.com>
 <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
 <aipSKbQGy587OCvU@localhost>
 <CAOU6tADWXsiAWdWJ8gBMs-=gBcsZKFpxsRDg8qcOw54-1h+daw@mail.gmail.com>
 <aiqygAMj0p3ebEhI@localhost>
Message-ID: <CAOU6tAAye0bAhdt0XPvVGdw_FAgRgSFFse4mJgK6w+XCVBgB=Q@mail.gmail.com>

Hi,

> a flourishing jungle of different CIs running basically the same tests
> in slightly different environments is not a good idea, for packages
> with fragile tests it can be outright harmful.

This same argument could justify maintainers not running autopkgtest
locally on their packages, but instead uploading to unstable and
re-uploading until autopkgtest passes on ci.debian.org. I don't think
that is really how you would want maintainers to behave.

> The ideal number of CIs is one, more is worse.
>
> Trying to push maintainers to use more than one CI is bad,
> this is often a waste of not only resources but also precious
> maintainer time.

Did you read my proposal 4 days ago with an open mind? Based on
replies everyone just jumped to the conclusion they already had.

I wrote:
> Specifically I'd like to float the idea that IF a project uses Salsa
> CI, AND IF the Salsa CI was failing (red) for the git tag
> corresponding to the upload (vcswatcher already has this data), the
> migration would be delayed by 10 days.

This would actually _discourage_ people from using Salsa CI if they
don't even bother looking at the results and just waste both machine
and human resources in vain.

- Otto


From bunk at debian.org  Thu Jun 11 17:38:32 2026
From: bunk at debian.org (Adrian Bunk)
Date: Thu, 11 Jun 2026 19:38:32 +0300
Subject: [Debian-salsa-ci] Release team to utilize Salsa CI for Forky
 quality assurance?
In-Reply-To: <CAOU6tAAye0bAhdt0XPvVGdw_FAgRgSFFse4mJgK6w+XCVBgB=Q@mail.gmail.com>
References: <CAOU6tABLT+8wxLTtwhw7_rDawktsvkR-apW=0R2rG0KvYWjCfw@mail.gmail.com>
 <CAOU6tADFFbg_MK3obNu1z_a49CNV6AfFKfTJ2Beq5o-jP6jcrg@mail.gmail.com>
 <aiWXhdSPbhHBxBqi@ramacher.at>
 <CAOU6tAB_rJpEC3By=4P1xrvGo3nNfP57U05A-48=o5ym9Of3Vw@mail.gmail.com>
 <aiW5XKsplsYy5XUG@ramacher.at>
 <CAOU6tAB89L00aGZQ5sd6rAYdrC2VVURMQ-xZ_aV_XctaSOQveQ@mail.gmail.com>
 <aipSKbQGy587OCvU@localhost>
 <CAOU6tADWXsiAWdWJ8gBMs-=gBcsZKFpxsRDg8qcOw54-1h+daw@mail.gmail.com>
 <aiqygAMj0p3ebEhI@localhost>
 <CAOU6tAAye0bAhdt0XPvVGdw_FAgRgSFFse4mJgK6w+XCVBgB=Q@mail.gmail.com>
Message-ID: <airkiKDjyX5uB7H_@localhost>

On Thu, Jun 11, 2026 at 11:13:37PM +0800, Otto Kek?l?inen wrote:
> Hi,

Hi Otto,

> > a flourishing jungle of different CIs running basically the same tests
> > in slightly different environments is not a good idea, for packages
> > with fragile tests it can be outright harmful.
> 
> This same argument could justify maintainers not running autopkgtest
> locally on their packages, but instead uploading to unstable and
> re-uploading until autopkgtest passes on ci.debian.org. I don't think
> that is really how you would want maintainers to behave.

does it make sense to run autopkgtest locally before an upload that will 
result in an exhaustive CI run?
There is no general answer to that.

Spending manual work for trying to avoid that the CI finds issues can 
easily be a waste of time. There is a tradeoff between effort and 
benefits, and I am e.g. usually not running autopkgtest for my NMUs 
before uploading unless I am explicitly fixing an autopkgtest in the 
upload. More than 99% of my uploads are NMUs and I am sometimes doing 
more than 100 per week for fixing RC bugs, which would make always 
running autopkgtest a significant waste of time for me.

Most important is that uploaders check the testing migration status of 
their packages, because neither local testing nor Salsa CI will find
the big endian breakage that blocks migration.

> > The ideal number of CIs is one, more is worse.
> >
> > Trying to push maintainers to use more than one CI is bad,
> > this is often a waste of not only resources but also precious
> > maintainer time.
> 
> Did you read my proposal 4 days ago with an open mind? Based on
> replies everyone just jumped to the conclusion they already had.
> 
> I wrote:
> > Specifically I'd like to float the idea that IF a project uses Salsa
> > CI, AND IF the Salsa CI was failing (red) for the git tag
> > corresponding to the upload (vcswatcher already has this data), the
> > migration would be delayed by 10 days.
> 
> This would actually _discourage_ people from using Salsa CI if they
> don't even bother looking at the results and just waste both machine
> and human resources in vain.

This has nothing to do with the quality of the binaries in unstable, 
which is the reason why the Release Team has rejected your suggestion.

> - Otto

cu
Adrian



