Hi! > > Thus I wanted to ask if the Release Team has had any internal > > discussions on how to better utilize Salsa CI for ensuring Forky has > > minimal amount of regressions? > > I recall you asked this question before. (I didn't bother to search for > it). Before diving into specifics, let me ask the question: what exactly > are you trying to achieve with the questions you raise?
>From the end of my email: "I do however feel that the Release Team should in *some* way reward packages and maintainers who diligently keep CI green and quality high to foster a culture that testing, reading test results and proactively caring about quality is valued." > > Are there any new quality assurance tools you would like the Salsa CI > > pipeline to run by default on all Debian packages in an effort to > > prompt maintainers to ensure those tests pass? > > > I think salsa-ci is already trying to track what we use, and more. Maybe > it's good to be aware of a recent change in britney2 where we made some > lintian tags blockers: > https://salsa.debian.org/release-team/britney1/-/blob/master/britney?ref_type=heads#L197 If those tags are errors in Lintian, the Salsa CI Lintian job would fail and flag these immediately. > There is bug #944459. Roger that, filed https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/535 now. > > Are there any plans to incorporate the Salsa CI status in unstable -> > > testing migrations? .. > Which checks in salsa-ci do you see regularly failing that we don't > already check with the current policies in britney2? How to determine It's not about the individual tests, but about the culture of actually caring for testing _before_ upload. There are hundreds of examples of packages that failed in builds or autopkgtests or piuparts where the failure was easily visible on Salsa CI, but the maintainer didn't bother to test (either they didn't use Salsa CI, or they had it enabled but didn't bother to check the results). For example yesterday I was looking into etcd failures on autopkgtests which actually already were visible prior to upload, but the person doing the upload didn't bother to look at Salsa CI because of cultural issues. > "if the git repo is up-to-date with what was uploaded"? CI in salsa > (AFAIK) can be tuned per repository, in my opinion we would need to know > what is enabled and what is disabled in the pipeline to judge anything. I don't think you need to check the jobs, you are now focusing on too small of a detail and not the bigger picture. You can just use the status vcswatch is already giving about if the contents was pushed to git or not, and if there was a passing CI or not. Who knows, vcswatch might in future even check CI status from other forges than just Salsa and if the Release Team wants to promote a better testing / CI culture now by using the vcswatch results it would carry over to any future forge or CI system kind of automatically.
