Hi Otto,
On 18/11/2024 04:27, Otto Kekäläinen wrote:
Hi!
I was reading https://lts-team.pages.debian.net/git-workflow-lts.html
and have a couple of questions:
1. Why use `debian/.gitlab-ci.yml` instead of `debian/salsa-ci.yml`?
As Sylvain mentioned, that's for historical reasons, as an old script (not used
anymore) used to create repositories from scratch, and added that file. Now we
prefer to fork the maintainer repository instead, so if that uses
debian/salsa-ci.yml, we'll do so too. We could rename things to salsa-ci.yml for
existing repos, but I think there's little benefit to justify spending time on that.
The documentation should be updated though, as it mentions salsa-ci.yml in one
place, then .gitlab-ci.yml in another.
2. Why run `git checkout -b upstream` and not `git checkout -b
upstream/latest` as per DEP-14?
I don't mind either way, especially if gbp.conf points to the right branch.
Which brings us to...
3. Why do you delete `debian/gbp.conf` and then pass all gbp configs
manually each time? Would it not be much easier to replace the
`debian/gbp.conf` with one that includes `debian-branch =
debian/stretch` etc lines?
Agreed. I tend to do that, and wasn't aware that that document suggested to drop
that file.
4. Why do you maintain a fork of Salsa CI at
https://salsa.debian.org/lts-team/pipeline? Why not submit all
pipeline improvements upstream to Salsa CI and instead of
https://salsa.debian.org/lts-team/pipeline/raw/master/recipes/buster.yml
use https://salsa.debian.org/salsa-ci/pipeline/raw/master/recipes/buster.yml?
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.
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.
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.
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.
Cheers,
Emilio
