| I think we exagerate the salsa CI load concerns. My perception is that while the Go package system is substantial, the churn is actually fairly low and building Go packages is much faster than most Debian packages. Remember that the CI only runs after a manual human commit and push. It usually takes more time for a human to think about and commit a change than CI consumes to run a pipeline for it.
I also prefer to push salsa CI changes first and then resume discussion about branch naming style. Changing things have a big cost since we are not likely to do so for all packages, so the old approach will still be around. Understanding and working with many different styles adds cognitive load. /Simon 7 dec. 2024 kl. 00:09 skrev Reinhard Tartler <siretart@gmail.com>:
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
|