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 am not a member of the Release Team, but I wonder what information > you have in mind that is not already being available and used by the > britney CI?
It is not about the specific tests in Salsa CI, but merely the fact that some maintainers are trying to be diligent and test their packages properly _before_ upload, and some just upload and skip doing proper QA activities. As I wrote at the end of my question I was wondering if the Release Team wants to promote such a culture. > > 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? > > AFAIK your "on all Debian packages" is factually incorrect, with > resource limits in the Salsa CI preventing the build of many packages. I am aware only of qt6-webengine not being able to build on Salsa (https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/506). I also assume the resource issues are easy to solve if enough people report them and ask them to be solved, as the limitations are in policies and not in software or pipeline itself. Anyways, if you read my proposal it does not require that all packages use Salsa CI, I am just asking if packages that do use and are green can get rewarded and those that are failing already before upload slowed down in their transition. It could actually help if the Salsa CI status mattered for the transition, as maintainers that inherited packages with Salsa CI enabled but ignored would disable it and stop wasting resources on testing in vain. ... > If something has provably regressed, this should already block testing > migration due to failing also in the britney CI. Again, it's not about the individual jobs. Any maintainer can anyway customize their salsa-ci.yml file. This is about the culture of testing changes in CI _before_ upload, and about maintaining the ability to see from the CI which commit or merge request caused the regression. Having this capability and culture most likely leads to higher quality and fewer regressions to fix at release time. .. > A maintainer task relevant to the Release Team not currently covered by > our infrastructure are test rebuilds for transitions. Providing this as > an optional step in the Salsa CI would be very useful for maintainers. There is an optional job for rebuilding reverse build dependencies: https://salsa.debian.org/salsa-ci-team/pipeline#build-reverse-dependencies This is however not something that should be permanently enabled in a CI.
