Re: golang-golang-x-mod 0.19.0 -> 0.29.0?
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. 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.
> 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?
> 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.
> 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 thought that proposing changes on the
mailing list like I did in
https://lists.debian.org/debian-go/2024/12/msg00021.html last year and
waiting for few months is a reasonable way to gather consensus but I
am starting to think that we need to have a some kind of voting or
list of decision makes who are allowed to make changes. Getting people
to vote on MRs could be an option.
I have a MR at https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests/10
to publish the proposal so people can read it, but it has zero
"thumbs" up or down. The current policy has gaps and TODO items that
have been there since 2017 and nobody is maintaining it
(https://salsa.debian.org/go-team/go-team.pages.debian.net/-/blame/master/workflow-changes.asciidoc),
should it really be used as a guideline forever? What is the process
to change it? There are also a bunch of improvements pending at
https://github.com/Debian/dh-make-golang/pulls that I'd like to see
adopted, and also Arthur has done a great job with
https://salsa.debian.org/go-team/flight-deck that could potentially
take care of maintaining the Go team repository configs, but Debian
teams don't really have any decision making process, so there is no
clear way to proceed unless there is suddenly a group of people who
get active on the mailing list.
Reply to: