> > 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.
