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 <o...@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 <o...@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)
