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.
