Re: scripts for DEP-14 migration
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
Reply to: