Otto Kekäläinen <otto@debian.org> writes: > Hi all Go team members, > > I am proposing we update the Go team workflow for 2025 on a few points: Thank you! Good to start discuss this. > 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. Would removing the old 'upstream' branch mean that all git repositories we have are useless for rebuilding old packages? 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. > 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? > 3. Stop modifying upstream path and only touch debian/* > > Most packages in Go seem to use quilt instead of gbp pq, which leaves > around .pc files. Also most packages seem to output in dh rules to > _build instead of debian/.. like everything else in dh does. This can > be fixed by merging https://github.com/Debian/dh-make-golang/pull/230 > and start to apply to new packages. +1 I didn't look at that patch, but I really found the current .pc hacks strange and agree we should not touch anything beyond debian/. > 4. Start running Salsa CI on Go team packages manually > > The current Go team CI run is incomprehensible to me. It does at least > *not* test the most important thing a CI in Debian should do, which is > to tell if a package builds in Debian or not. This can be fixed right > away by making manual extra Salsa Ci runs easy with > https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 +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? > 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 > If people agree with these suggestions and we are OK to proceed with > it, I can continue to work on them coming months, as well as submit MR > to update https://salsa.debian.org/go-team/go-team.pages.debian.net to > have everything up to Debian 2025 standards level. Yay! /Simon
Attachment:
signature.asc
Description: PGP signature