Otto Kekäläinen <otto@debian.org> writes: > Hi! > >> > You can simply copy the line `upstream-vcs-tag = v%(version%~%-)s` >> > from the template - it works without any modifications for your >> >> I added that here, and did an 'gbp import-orig' and things look >> different, is this correct? >> >> https://salsa.debian.org/jas/golang-golang-x-time/ > > Looking at the commit graph > (https://salsa.debian.org/jas/golang-golang-x-time/-/network/debian%2Fsid?ref_type=heads) > it seems correct to me, the upstream release tag is merged on branch > 'upstream' which is used by git-buildpackage to represent upstream > release. Thank you for review! I made an upload. > 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? >> I'm going to update that package too, and people think that repository >> looks better, I can fix the other x-* packages too. > > There are also other things that could be improved, like using branch > names debian/latest and upstream/latest. Maybe at this stage the main > point here is that you try this out and collect some experience on how > it works and then you can express an opinion on the choice later? Sure! Although it feels a bit aggresive to change branch layout on a first team upload of a package. My preference is 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). I realize everything in this field may be considered opinionated by someone. Some of my own preferences are in conflict. 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. >> Is this documented anywhere? This seems like a rather subjective and >> possibly opinionated configuration, and I'm wondering if the fact it is >> not part of debian/gbp.conf is that only some people prefer this way. > > That is a valid point. I think git-buildpackage is too un-opinionated > and allowing users to do whatever they want, and the docs )e.g. > https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.intro.html) > don't clearly express what are the best practices. And some people consider git-buildpackage by itself opinionated. >> Is there concensus on changing Go Team policy on this? I really don't >> care except for consistency on this. I think we are likely to keep >> repeating the same mistake (and discussion) otherwise. > > How do we measure consensus? I don't know -- I'm a new team member, and I share your frustration about making team-wide decisions, but I don't have any answers. /Simon
Attachment:
signature.asc
Description: PGP signature