Re: Proposing 2025 workflow changes for Go team
Hi!
Five days later, the script and proposal to execute enabling Salsa
instance runners still has zero approvals..
While waiting to get approvals on my code suggestions, I will also
draft a workflow 2025 proposal at
https://salsa.debian.org/go-team/go-team.pages.debian.net like was
done in 2017 to paint the full picture of all my proposals combined
help to optimize the Go packaging workflow.
On Thu, 2 Jan 2025 at 00:27, Otto Kekäläinen <otto@debian.org> wrote:
>
> Hi all!
>
> Next step in this list would be number 5.
>
> Changing defaults for new packages and a script to bulk update all
> existing repositories posted at
> https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/4
> Feedback welcome!
>
> On Thu, 5 Dec 2024 at 21:58, Otto Kekäläinen <otto@debian.org> wrote:
> >
> > Hi all Go team members,
> >
> > I am proposing we update the Go team workflow for 2025 on a few points:
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
> > 5. Enable Salsa instance runners in Go team and run Salsa CI automatically
> >
> > 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.
> >
> >
> > 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.
> >
> > - Otto
> >
> > PS. All MR and PR above have the +1 feature, so if you like them, I'd
> > appreciate seeing your thumbs up on them :)
> >
> > PPS. Even though I an new to Go team, I am confident that these
> > suggestions work well in practice, as I have recently sponsored two
> > packages and worked on 5 myself. I have also about 25 years of
> > experience of Debian and software development in general, which of 10
> > years as DD, and I am a contributor to both a bunch of the tooling
> > used in Debian (Salsa CI, git-buildpackage, devscripts, Lintian ...)
> > and the documentation about it (policy, developer's reference, debmake
> > doc ...) as seen e.g. via MRs I've submitted
> > (https://salsa.debian.org/dashboard/merge_requests?scope=all&state=all&author_username=otto)
Reply to: