Hi Simon, I would definitely love to see upstream-vcs-tag used more often.
The primary challenge with this is that it currently requires manual setup of the upstream remote. Failing to perform this manual setup results in an error, which is useful because otherwise the packaging repository won't have the upstream Git history. I personally find the upstream Git history very valuable, though I understand that some developers will disagree due to different packaging style preferences. For the team, I understand that we did settle on DEP-14, which does seem to mandate including the upstream history. The unfortunate aspect is the error behavior when one misses setting up the proper upstream remote. I wonder whether we can improve the tooling to make missing this step less surprising, particularly to less experienced packagers? Best regards, Reinhard On Fri, Nov 21, 2025 at 9:23 AM Simon Josefsson <[email protected]> wrote: > I made the change to golang-golang-x-text too, and uploaded it. > > This is systematic across most Go packages. > > Is there anyone who think that debian/gbp.conf should NOT contain the > relevant 'upstream-vcs-tag' label? > > I'm wondering if we should use it for all Go packages. Right now I > think it is only used in a smaller minority of packages, at least I > rarely seems to notice it in existing packages. > > It is possible to make reasonable arguments against (e.g., it move > things further away from a tarball-centric upstream view), but I'm not > sure if anyone feels strongly about it. Otto has posted good argument > for using it. > > If we make a decision, it would be nice to improve tooling somehow to > notice lack of it. Right now none of the QA tools I use even suggests > anything about this. > > I don't care either way, although if I was forced to chose I would use > it, but I do care for consistency since eventually common idioms and > patterns save everyone time. So I would be happier if we use it for all > packages, or for no packages. Maybe this should be implicit through > DEP14. It may be that we are essentially stuck on reaching any form of > agreement, though, and things continue to be per-package tradition. > > /Simon > -- regards, Reinhard
