On Thu, Jun 11, 2026 at 11:13:37PM +0800, Otto Kekäläinen wrote: > Hi,
Hi Otto, > > a flourishing jungle of different CIs running basically the same tests > > in slightly different environments is not a good idea, for packages > > with fragile tests it can be outright harmful. > > This same argument could justify maintainers not running autopkgtest > locally on their packages, but instead uploading to unstable and > re-uploading until autopkgtest passes on ci.debian.org. I don't think > that is really how you would want maintainers to behave. does it make sense to run autopkgtest locally before an upload that will result in an exhaustive CI run? There is no general answer to that. Spending manual work for trying to avoid that the CI finds issues can easily be a waste of time. There is a tradeoff between effort and benefits, and I am e.g. usually not running autopkgtest for my NMUs before uploading unless I am explicitly fixing an autopkgtest in the upload. More than 99% of my uploads are NMUs and I am sometimes doing more than 100 per week for fixing RC bugs, which would make always running autopkgtest a significant waste of time for me. Most important is that uploaders check the testing migration status of their packages, because neither local testing nor Salsa CI will find the big endian breakage that blocks migration. > > The ideal number of CIs is one, more is worse. > > > > Trying to push maintainers to use more than one CI is bad, > > this is often a waste of not only resources but also precious > > maintainer time. > > Did you read my proposal 4 days ago with an open mind? Based on > replies everyone just jumped to the conclusion they already had. > > I wrote: > > Specifically I'd like to float the idea that IF a project uses Salsa > > CI, AND IF the Salsa CI was failing (red) for the git tag > > corresponding to the upload (vcswatcher already has this data), the > > migration would be delayed by 10 days. > > This would actually _discourage_ people from using Salsa CI if they > don't even bother looking at the results and just waste both machine > and human resources in vain. This has nothing to do with the quality of the binaries in unstable, which is the reason why the Release Team has rejected your suggestion. > - Otto cu Adrian
