Hi!
> > 1. Switch to most recent and final DEP14 names 'debian/latest' and
> > 'upstream/latest': https://github.com/Debian/dh-make-golang/pull/225
> >
> > Go team already follows DEP14 since 2019, but the standard evolved, so
> > Go team should update accordingly. We can start doing this in new
> > packages by merging the PR above, and then later update old packages
> > by using upcoming dep14-convert script from devscripts.
>
> How does that work? As far as I know, you cannot both have a 'upstream'
> branch and a 'upstream/latest' branch.
You can try running the script. It just renames tha branches. No
history is lost. Everything will continue to work.
> Would removing the old 'upstream' branch mean that all git repositories
> we have are useless for rebuilding old packages?
Nothing becomes useless. As long as debinan/gbp.conf has correct
branch names (which it will have before and after rename) then
building will automatically work all the time.
> Alas I think to some extent that is already the case though since the
> pristine-tar branches have sometimes been purged, which is unfortunate
> since it complicate rebuilding of earlier versions in the git
> repository.
I would never propose anything that throws away git history, that
would be a stupidly unacceptable tradeoff and not an improvement to
me. This is not what I am suggesting to be clear.
> > 2. Use name 'upstreamvcs' for upstream instead of 'upstream'
> >
> > See https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/3.
> > This makes use of DEP14 easier, and makes Go team guidance also
> > compatible with `gbp clone vcs-git:<package> --add-upstream-vcs`
> > command.
>
> Is there any wide adoption of this pattern? I find it ugly. What is
> the reason? To avoid clashing with upstream/latest branch? If so how
> about simply calling the remote 'up' instead?
That is certainly up for discussion. I just wish we align with what
git-buildpackage has instead of inveting our own naming scheme.
Do you want to file a bug report git-buildpackage to start a
discussion on optimal upstream remote name?
> > 3. Stop modifying upstream path and only touch debian/*
..
> +1
...
> > 4. Start running Salsa CI on Go team packages manually
..
> +1
> Yes - although can we do without using upstream/downstream? Just use
> the normal Salsa CI pipeline, but add the current test_the_archive as a
> separate job. Doesn't that work?
Yes, proposal step 5. is to improve it but I think we need to do 4.
first and then assess the situation. We also need somebody to step up
and explain/document the current `test_the_archive` so we can
holistically develop a full pipeline. The step 4 is just something
that can be added without touching how `test_the_archive` works now.
> > 5. Enable Salsa instance runners in Go team and run Salsa CI automatically
>
> +1
..
> > Once 4 is done, we can further tweak the Salsa CI template to best fit
> > Go team, and in maybe 3 months follow up by getting a setup that
> > automatically runs at least the package build, autopkgtest and Lintian
> > jobs from Salsa CI.
>
> +1
Thanks!
Looking forward if others also agree this makes sense.
Points 4 (invoke salsa ci) and 5 (add the salsa instance runners) get a strong +1 from me. I'm wondering whether we can roll out that change gradually, because I would hate to see a situation where this would cause salsa do fall over because of the sudden additional load the go team puts on the infrastructure.
Point 3 also sounds fine to me.
As for renaming branches (points 1 and 2), I'm not convinced it's worth the trouble. Let's focus on 3, 4 and 5 first. That's going to bind quite a bit of resources and attention anyways.