Re: debian/gbp.conf upstream-vcs-tag (was: Re: golang-golang-x-mod 0.19.0 -> 0.29.0?)

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 <simon@josefsson.org> 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