On Sun, Jan 04, 2026 at 09:40:31AM -0800, Otto Kekäläinen wrote: > 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.
I am not sure there is a clear distinction between "diligent" and "waste of time" here. The proper QA happens after uploading to unstable (or experimental), and whether having more than one CI in the workflow makes sense is something that should IMHO be left to the maintainer. > > > 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). If there is a ranking of the packages with the largest build times on amd64 somewhere, I doubt qt6-webengine would make it into the TOP 100. webkit2gtk, LLVM, GCC, OpenJDK, acl2 - that's just random packages coming into my mind with much larger build times. > 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. My guesstimate would be that your "easy to solve" might end up being at least an order of magnitude more CPU power. RAM and disk space are also issues, you could not build all packages on a worker that has only 50 GB disk space. Speed also matters here, a maintainer might not want to wait a week for Salsa CI results and then another week for complete britney CI results. >... > > 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. >... I do not understand this claim. Anything automated CI can find should already be found by the britney CI immediately and block testing migration. cu Adrian
