Hi Otto, On Tue, Aug 20, 2024 at 06:35:52PM -0700, Otto Kekäläinen wrote: > In short: > 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? > > > Background: > We have had several cases recently where an upload to Debian unstable > causes widespread failure in unstable, and it could have been easily > prevented if Salsa CI pipeline had run for the package and revealed > the problem before upload to archive for everyone to suffer.
I'd like to rephrase your quest. What you really want is unstable to be less unstable. Whilst a number of people disagree with that notion, I sympathise with that view. We do use unstable to discover problems before hitting testing, but in order for this to be effective, the bugs to find should mostly be integration problems and it shouldn't be too bumpy to let actual users ride unstable and report non-obvious problems. Your proposal here is to improve the situation using salsa-ci and it is not the worst of ideas given that salsa-ci works well for large numbers of packages. One complaint I've seen about this workflow and one that I agree with is the waiting time. Checking salsa-ci before uploading incurs an extra context switch. What we'd really like to do is click the equivalent to "Auto-merge" (if the pipeline passes). As I write this, Sean or Ian will likely come along and say tag2upload. Working in this direction and enabling a "upload if ci passes" would bring the salsa-ci experience to another level. Let me suggest that there are more ways to do this. Freexian is putting a ton of effort into https://debusine.debian.net. It can do much of the same tasks as salsa-ci already (with less flexibility). Extending it to act as an upload-proxy that forwards your upload to the archive if builds pass could be another option of improving unstable quality. In earlier times, debomatic.debian.net was used as a pre-upload QA tool if I remember correctly. Then the top-150 packages tend to be packages with unusual aspects. For instance, the git repositories for gcc-VER, glibc and linux all lack upstream sources. For linux, there is a pipeline, but in order to complete in a timely manner, it enables the pkg.linux.quick build profile and the pipeline is elaborate with a complex extract-source stage. It's not a matter of just enabling the pipeline for our core packages but spending a lot of time fiddling with the settings until it works. I guess that sending a working pipeline configuration for these could improve the situation. Would it also make sense to source dedicated gitlab runners for heavy core packages to further reduce the feedback time and the impact of enabling CI there? Given this I want to resonate what others already said. This seems more like something to put effort into and make it work practically than worth discussing. Doing a survey mail to the relevant maintainers for figuring out where to best direct that effort also seems sensible to me. More than once, I've experienced that it's not the technically best solution that ends up working well, but the one that has the best support crowd. To be blunt, I don't think the /usr-move we do in DEP17 is the technically best solution, but most people seem to be happy with the level of support. Thanks for working on making unstable more enjoyable! Helmut
