I think this anecdote is actually quite relevant to this design discussion:
>On Thu 04 Sep 2025 at 05:18pm +01, Ian Jackson wrote:
>> Sean Whitton writes ("Bug#1111331: git-debpush: check if CI passed before
>> tagging"):
>>> For two complex packages I upload, sbcl and Emacs, the CI pipelines on
>>> salsa were set up by other people and always fail. I've never looked at
>>> them, leaving it to them. So such a default would very much get in my
>>> way. So ideally we can come up with something more subtle.
>>
>> I'm tempted to suggest that if you have a CI pipeline that always
>> fails you ought to get rid of it :-).
>
> Yeah. In these cases it's not really mine to delete, basically.
If you look at
https://salsa.debian.org/common-lisp-team/sbcl/-/pipelines?page=5&scope=all
you can see the CI was passing in late 2022 and started failing on
Lintian errors in your commit in 2023. If I was the maintainer, I
would stop all development and fix the failure. If it is not fixed
immediately, people will get "alert fatigue" and the CI will continue
to regress more and it is unlikely nobody will ever fix it. Now it is
so broken I'd recommend to just disable it completely, and not
re-enable it until someone has time to fix all the issues preventing
CI from passing.
Maintaining the package in a regression-free state (and compliant with
new Lintian versions and so forth) should not be the burden of one
diligent maintainer who goes around and cleans up after others made
changes and broke stuff. If a package has CI enabled, it should mean
that anyone touching the package needs to participate in maintaining
it. If maintaining CI is too hard due to e.g. large or complex package
issues, then the maintainers should agree to just decrease the CI
scope or completely disable it. If CI passes or not should be an
attribute for the package/project, not a per-maintainer preference
thing.
Thus my suggestion here is that all tag2uploads should check if CI is
enabled or not, and require that CI must be green. I don't think it is
a good idea to introduce a new config file in the context of CI (but
maybe you have other things that need configuration). The repository
commit/tag already has metadata in the forge if CI was enabled, and
that information should be used instead of requiring maintainers to
create new files to express the same thing.
