Hi! Thanks Sylvain for your reply. Hopefully others on the LTS list can also chip in too, so we get more more data points and views.
> > 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.) Can this be updated and aligned to be debian/salsa-ci.yml everywhere? If there is no reason to have custom name, it would be easier long-term to just have the same practice everywhere. > > 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. I'd say most repos do follow it, and that DEP-14 is de-facto what all tools are unifying on. Mass converting old repos is one thing (and might never be done), but it would make sense to have all process documentation follow DEP-14 for all future work, right? > > 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. Thanks. That is a good reply - now I know there was no magic reason, and that this is probably a thing that would make sense to suggest to be changed. > > 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 :)) I am the submitter or reviewer in those MRs, so I am aware that this was mentioned there, but it was in relation to the MR topics and not explained properly, so I specifically wanted to seek out if anyone on the LTS mailing list can give a self-standing 2-3 paragraph explanation of what is the reasoning behind such a design/architecture and background of current state (without mixing it with a discussion about changes elsewhere).
