Re: golang-golang-x-mod 0.19.0 -> 0.29.0?
> > Anyway, as long as you have sensible settings in debian/gbp.conf the
> > `gbp import-orig --uscan` will do the correct thing, and seems it did
> > in your example.
>
> What about --sign-tags? I tend to supply it myself on the command-line.
>
> I'm not sure it really provides any strong advantage, but OTOH it
> doesn't cost a lot to use.
>
> Should 'sign-tags = True' be added to gbp.conf generally? Would someone
> find that annoying? Why?
So maybe now read https://lists.debian.org/debian-go/2025/11/msg00006.html ? ;)
> 1) use whatever style earlier contributors used in each project. If it
> is a complete mess, try to make minor incremental consistency
> improvements following the Go team policy, or 2) below but avoid making
> changes that may be (too) opinionated.
>
> 2) DEP14, debian/latest, wrap-and-sort -satbk, debian/gitlab-ci.yml
> being the Go team pipeline, debian/salsa-ci.yml being a Salsa pipeline
> with any per-project specific configurations (e.g.,
> SALSA_CI_DISABLE_LICENSERECON: 0), use dh-sequence-golang, tag2upload,
> use pristine-tar branch iff upstream makes tarball worth preserving
> (e.g., not GitHub auto-generated ones).
Makes sense.
> I realize everything in this field may be considered opinionated by
> someone. Some of my own preferences are in conflict.
Kind of, but then again they are all improvements possible due to new
things being available in past years and it would be counterproductive
to categorically refrain from using them just because it might be
inconvenient to somebody. In general I think it is better to use new
stuff, but write proper git commit messges and
debian/README.source(.md) to justify everything and to listen if/when
people come up with counterarguments. Only by constant interaction on
different packages and with multiple maintainers can we discover what
is the best workflow.
> Also I don't know how to handle master->debian/latest migration, would
> you remove or leave the old master branch? Some people seems to remove
> the old branch, and some people let it stay around. Removing it causes
> data loss and you lose the ability to re-build earlier versions from git
> using identical setups. I've been leaving the old branch around, but it
> looks ugly, and re-building (identical) old versions from git is not
> likely to work anyway for plenty of reasons.
I would just do what dep14-migrate from devscripts suggests to do.
Anyway a branch is just a reference to the "tip" commit. All old
commits will still stay even with new branch name, nothing is lost in
adopting DEP-14 naming scheme.
Reply to: