I was +1 on Otto's earlier proposal, but I think waiting for an upload for each package is prone to fragmented uptake. We are likely to have changed policy before we've finished implementing this one. I didn't know there was tools and knowledge on how to make small targetted fixes to hundreds of packages in git like Lucas has shown. Now I think we should apply whatever changes we as a team believe is the right choice all at the same time, so we get better consistency. I hope Lucas have cycles to do the update for us, unless someone else wants to learn how to.
So I think: 1) Can we establish consensus in the Go team that doing mass-fixes a'la Lucas approach is a good idea? Otherwise let's fall back to Otto's proposal to do incremental changes over time. 2) Can we make a list of things we can agree on are minimal requirements for consistency? I think the Go Team policy is fairly close to what Lucas did for Ruby packages, with possibly the only exception being enforcing use of pristine-tar. I'm not sure there is agreement to enforce non-use of pristine-tar in the Go team either. I think that for Go packages with a long history of using pristine-tar, we should continue to respect that. So I suggest not touching this worm-hole and just enumerate other changes that we can agree on. Thoughts? /Simon tis 2025-08-26 klockan 08:45 -0700 skrev Otto Kekäläinen: > Hi! > > I am all in favor of these changes as I suggested mostly the same a > year ago. I just hope we can do the migration in a slow and > controlled > way, and upgrade all tools and currently outdated docs in the > process. > > > On 26/08/25 at 10:05 +0200, Simon Josefsson wrote: > > > Perhaps the debian/salsa-ci.yml should contain something like > > > this: > > > > > > include: > > > - > > > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml > > > - > > > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/team.yml > > > > You could even set it to: > > > > ---- > > include: > > - > > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/team.yml > > ---- > > > > and add the include of > > https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml > > in pkg-go-tools/pipeline/team.yaml > > > > (see "management of debian/salsa-ci.yml" thread in > > https://lists.debian.org/debian-ruby/2025/08/threads.html) > > On the Go team list multiple people have raised a couple of times > that > the custom Go CI job actually does not test things that are useful > for > the specific package it runs for. My proposal is to fully replace it > with vanilla salsa-ci.yml, and start out by having both > debian/gitlab-ci.yml and debian/salsa-ci.yml in parallel so that > project settings can be migrated over time with both new and old > working in parallel: > https://github.com/Debian/dh-make-golang/pull/279. > > In general I'd suggest we > 1. first make sure dh-make-golang creates *new* projects with optimal > settings > 2. then convert projects semi-automated by only one at a time when a > human is uploading and can check everything went fine > 3. only finally after 6-12 months seeing all is good with new and > converted projects do a mass migration for the remaining ones > > For reference previous threads on the topic: > * https://lists.debian.org/debian-go/2024/12/msg00021.html > * https://lists.debian.org/debian-go/2025/01/msg00045.html
