[Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?

[Theodore Ts'o]

On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote:
> 
> In short:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?

Since I'm the e2fsprogs (one of the top-150 packages) maintainer, I
thought I would take a look at this.  And since I'm not super savvy
about Salsa --- e2fsprogs does have a Salsa git repro, but it's not
the primary.  My primary git repositories are on github.com and
kernel.org.  So I did a Google search for "Debian Salsa CI" --- and
found very little useful for me to understand more about Salsa CI.

For background, I am using Github's CI to make make sure that there
are no build regressions or new Salsa warnings on Linux, Windows, and
MacOS.  I also do test builds using dgit, wired to git-buildpackage
and building using schroot; the test builds run a Lintian check and
run e2fsprogs's "make check" regression test.  I'm not brave enough to
run Debian unstable on my Development system, so I will also do a
backport to Debian-testing built using git-buildpackage, and I do a
dogfood test run on my developer workstation before I upload.  Also,
aspart of my upstream development, I am regularly doing manual test
builds on Debian stable, and create debian packages for e2fsprogs
which are integrated into the gce-xfstests[1] test appliance and make
sure there are no test regressions found when running xfstests to test
latest kernel (but which sometimes pick up e2fsprogrs regression,
although 99.99% of the time regressions are picked up using
e2fsprogs's built-in regression test suite).

[1] https://thunk.org/gce-xfstests

So here are the questions that would be **really** nice if it was
easily accessible to a prospective Debain maintainer:

1) From a technical respective, what does Salsa CI buy me?  Is it just
doing a build and sources using "configure ; make ; make check"?  Is
it doing a dpkg-buildackage?  Is it going to do the equivalent of
autopkgtest?  Maybe it's in the Debconf 2019 presentation, the video
is #5 on the Google searches, but I was too lazy to roll the video.
If slides were easily accessible, I probably would have looked at the
slides, but I wasn't able to easily find them.

2) If I'm already using Github's CI, and have autopkgtest, what are
the benefits for using Salsa CI?  (Especially given the amount of
testing that I'm doing already, why should I spend more time enabling
Salsa CI?)

3)  What's the simple recipe for enable Salsa CI?

4)  Where do the results for Salsa CI end up getting reported?

Sorry if these were all stupid questions, but I couldn't find the
answers easily, so I figured I'd ask on this e-mail thread.  :-)

		     	     	 - Ted