I read through the latest build artifact and support these changes. I do generally dislike all this complexity, but harmonizing the Go team process with other DEP14 processes _reduces_ complexity for me. Otherwise I have to deal with the complexity of the modern DEP14 approach AND the complexity of the older Go style approach. So for me, the overall complexity goes down, even if it mildly goes up compared to the old Go packaging style.
As far as I know, practically no upstream Go vendor publishes tarballs. Use of 'pristine-tar' is thus somewhat weird, in that we are only preserving something that GitHub produced (rather than upstream itself), and GitHub known to change the format once in a while. I don't mind enabling it (for consistency), but I feel the justification for this complexity is a bit weak. /Simon Otto Kekäläinen <o...@debian.org> writes: > Hi! > > In line with what I have already been doing, I now published a draft > for workflow changes at > https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/7 > > Direct link to latest build artifact for convenience: > https://otto.pages.debian.net/-/go-team.pages.debian.net/-/jobs/6917178/artifacts/build/workflow-changes.html > > Please let me know what you think per email or in MR. I think my > proposals mainly ensure that Go team is aligned with what most other > (modern) Debian packages do and there shouldn't be much controversial > about this. > > I am however willing to split up the changes in two phases if it looks > like some things are quick and easy to agree on, and some not. >
signature.asc
Description: PGP signature
