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

[Otto Kekäläinen]

Hi!

> > 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?
> Advertise widely and frequently that there is a pool of people which is
> happy to help investigating the failed CI jobs.
> Then start personally advocating the benefits of CI to the maintainers
> of these packages: I expect that in most cases you will find out that
> they are not using CI just because they are not well informed about it.

So maybe just send a mass email to the maintainers of these 150 packages?

> Recently I enabled CI for most of my packages, and the experience has
> been generally positive.

Glad to hear!

...
> Of course, this works best if a package *HAS* autopkgtests, so it would
> be great if more people contributed non-trivial tests to the packages
> they care about.

Autopkgtests are of course nice, but Salsa CI will also help detect if
the build is broken, or if e.g. debian/control relationships are
broken and package is uninstallable etc. The coverage is not complete,
but if the basic things that Salsa CI tests for break, then the
package is most likely going to cause havoc once it lands in unstable
and require an urgent re-upload. As examples, the failing build of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071245 broke
installation of gnupg on Debian unstable and thus everything that uses
gnupg and could have been prevented with simple Salsa CI run (the
package has now Salsa CI, so this won't repeat), or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021336 where pam
files tried to overwrite files in other key packages, breaking Debian
unstable installations and chroot creation for everyone would have
been caught by basic Salsa CI tests (MR to include Salsa CI suggested
in https://salsa.debian.org/vorlon/pam/-/merge_requests/20). Using
Salsa CI will save both the maintainer some headaches, and protect
everyone using unstable and doing packaging work from being affected
by a temporarily broken dependency.

> Something that many developers are probably not aware of is that they
> can enable CI for a repository with no code changes at all and with
> a single command:
>
>  salsa update_projects $NAMESPACE/$PROJECT \
>   --jobs yes --ci-config-path recipes/debian.yml at salsa-ci-team/pipeline
>
> (salsa(1) is part of devscripts)
>
> And then they can immediately schedule a new pipeline without having to
> push a new commit:
>
> https://salsa.debian.org/$NAMESPACE/$PROJECT/-/pipelines/new
>
> This allows to see how Salsa CI works with very low friction and no
> committment at all: worst case it can be disabled again and nobody will
> notice. :-)

Thanks, these are great to point out! i will add them to the Salsa CI
README in next docs update
(https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/519).