Hi Otto,
Thanks for your feedback :)
On 18/11/2024 04:27, Otto Kekäläinen wrote:
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`?
First, most of this was written by Anton (in Cc:) when mid-2022 when
experimenting with storing all LTS/ELTS releases in Git, IIRC motivated
by preserving some kind of history (especially in ELTS which doesn't
have snapshot.debian.org).
This evolved, a lot of some of the initial choices proved unfit and were
changed, some stayed, probably much can still be discussed/reworked :)
I suspect using a different .yml file was motivated by not clashing with
the initial package's, though I'm not sure there are actual use cases
for this.
(Of course now most of our repos are configured and populated to use
.gitlab-ci.yml and this is now a hassle to change back.)
2. Why run `git checkout -b upstream` and not `git checkout -b
upstream/latest` as per DEP-14?
TIL ;)
Most packages I've seen so far use a single 'upstream' branch (rather
than 'upstream/*') and gbp handles this gracefully even with multiple
upstream branches.
DEP-14 is till "candidate", so I'm not sure it's worth following this
when most of the repos we fork/merge don't follow this either.
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?
No idea.
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?
This was discussed recently:
https://salsa.debian.org/lts-team/pipeline/-/merge_requests/25#note_537744
(with pros and cons)
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)?
From what I understand there's already a discussion with you about this:
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/551#note_546985
(again with pros and cons :))
Cheers!
Sylvain Beucler
Debian LTS Team
