Hi! > As the initial author of the fork, I contributed some improvements that I > thought would be accepted upstream. However, I didn't think other changes > (such > as hacks to support jessie) would be accepted, as some of those hacks had been > removed previously. If the salsa-ci maintainers agree to include some of those > changes, I'd be happy to clean them up and submit them. But we'll still need > the > fork unless the salsa-ci project starts to build images for jessie ELTS > including freexian repositories, which I'm not sure is going to happen.
I think it is better we all contribute to one pipeline as there is only a handful of us volunteers around, at least currently. Thus, personally as Salsa CI contributor, I am OK if we now going forward keep in Salsa CI postpone dropping support for releases that are currently there, i.e. keep Bullseye until 2031-06-30. Resurrecting old releases is probably too hard. Also with my MariaDB packager hat on, it is much easier to do security/maintenance updates quickly for 3-8 different Debian and Ubuntu releases if there is a minimal amount of process/infrastructure changes required per release. > However, for LTS, we have made changes recently to use the salsa-ci bullseye > images, dropping them from our fork. The recipes et al can still be used from > the lts-team/pipeline project though. We did? Maybe that is easy to still resurrect if it wasn't long time ago. Bullseye isn't even ELTS but just LTS now, and I just did two months ago https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/18 and all testing was running on Salsa CI as base + per-package customizations. > > 5. Are you aware that the RELEASE does not need to be set manually at > > all? You can just keep the existing debian/salsa-ci.yml in the package > > and once you add a new changelog entry for stretch/buster/bullseye all > > the jobs in the CI pipeline will automatically build and test using > > the release in debian/changelog (only exception being Lintian, which > > currently always runs the Sid version)? > > I wasn't aware of that when I did the pipeline fork, that's the reason I added > release-specific recipes. That magic isn't going to work when a changelog > entry > contains UNRELEASED though, which is very common. I recently saw some > changelog > that had bookworm-security-UNRELEASED or similar, and I didn't think it was > for > this reason. However if one uses UNRELEASED, and sid is assumed and the > pipeline > breaks in unexpected ways (or worse, passes when it should fail) then that's a > bad assumption, and wouldn't have happened by explicitly setting the release > in > the CI config file, or by using a release-specific recipe. Just like we set > "branch-name = bullseye" in gbp.conf, instead of relying on guessing the > release > from d/changelog. You are right, when the first upload to a non-unstable is done and the most recent entry has UNRELEASED and all entries before it has 'unstable', there is no way for the autodetection to know that UNRELEASED actually means something else. Using 'bookworm-security-UNRELEASED' seems like a good way to solve it. > To me, the only reason to rely on that automagic is if we drop salsa-ci.yml > entirely and use a script to set the CI conf file to > `recipes/debian.yml@salsa-ci-team/pipeline' or similar. But then, since > there's > no config file in the repository, one cannot tweak things to e.g. ignore one > lintian tag, or disable the blhc job, or whatever, so again I don't see the > benefit. I would recommend to have the salsa-ci.yml file in the package explicitly. It is much easier to customize it and fix stuff if the CI pipeline is broken. If the CI pipeline is defined centrally, it is both invisible to contributors and forks, and it is impossible to fix if CI is failng due to CI issue, and then the package will be stuck with failing CI and the whole point with CI becomes moot. Also the CI config `recipes/debian.yml@salsa-ci-team/pipeline` would apply to all branches, and for example run on all pristine-tar branch pushes. It is much better to just have a CI file on each branch that controls exactly what that branch in that package does for CI.
