On Fri, Dec 6, 2024 at 1:28 PM Otto Kekäläinen <o...@debian.org> wrote:
> 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. -- regards, Reinhard
