Re: Use of 'debian/latest' in Go team as the default branch name
Hi,
On 24/01/2025 01:24, Otto Kekäläinen wrote:
Michael Stapelberg proposed in 2017 that the Go team should use
'debian/sid' as the default branch, in effort to unify with DEP-14 at
the time (https://go-team.pages.debian.net/workflow-changes.html#_new_workflow_3).
I feel it is important to highlight that this was not Michael's sole
work, it was the result of many long discussions involving most (of not
all) of the team's active members at the time and including an in-person
meeting at DebConf17 that I organised.
Turns out using 'sid' as the git HEAD wasn't a good idea, as it may
lead to flip-fopping between 'debian/sid' and 'debian/experimental' or
alternatively leading to uploads to experimental from a branch that is
named 'sid'.
I don't know how could this ever happen with the current guidelines,
where it is clear that if you want to release to experimental you need
to use the `debian/experimental` branch. In fact, using `debian/latest`
is what could cause this flip-flopping you mention. This paragraph alone
makes me wonder if you fully understand how the team has been working
for the past 7 years.
Hence in 2020 DEP-14 was updated and clearly recommend
'debian/latest' as the primary option now.
No. DEP-14 recommends that uploads are prepared "either in the
debian/latest branch or respectively in the debian/unstable and
debian/experimental branches", as you quoted. The `debian/sid` naming is
functionally and conceptually equivalent to `debian/unstable`, DEP-14
recommends the latter but it is not mandatory.
Can we agree to update the Go team policy to follow this and default
to 'debian/latest' going forward?
I strongly oppose this: not only it would create an enormous amount of
churn, but it is also a regression as many have already highlighted.
There are <2000 packages in Debian that use the 'debian/sid' branch
name, and out of these ~1300 are from the Go team. The Go team should
Yes, we were early adopters of this schema, and IMHO it has greatly
served us for years.
not diverge from general Debian practices unless there is a proper
cause. The current situation is only due to historical reasons.
It seems backwards to try to start this homogenisation effort with a
team that has had a pretty homogeneous workflow for years, instead of
tackling the mess that is the rest of the archive...
I don't see any good arguments to use 'debian/sid' on Go team forever.
Many good arguments were given and disregarded.
With a couple simple updates to our tooling we can slowly start
converging on the 'debian/latest' recommended by DEP-14. This is a
small but important detail in updating the Go team workflow for 2025
and converge on practices that are common with other teams, and
eventually simplify the workflow, and have it more productive for
current DDs and easier to learn for new and aspiring DDs.
This highlights something I have been feeling since the discussion
started: you are pushing pretty hard for changes on a team that you only
joined very recently, and where your only contributions seem to be
unilaterally applying your idea to existing packages. I don't want to
say that newbies should not try to instil new ideas and energy into the
team -quite the contrary-, but I think you should really try to follow
and understand current practices before proposing to change them.
..
I also want to say that I do like some of the changes you propose. In
fact, soon after we reached an agreement in 2017 I regretted having
settled on `upstream` and not `upstream/foo` as a branch name for
upstream commits, and I have informally used other branch names in some
packages (e.g. for repackaging).
I also like the use of `wrap-and-sort -tsa` (instead of just `-ta`),
which I have been using on my own packages for years, but it is a
aesthetic preference that should not be more than a recommendation or a
sensible default in the tooling.
OTOH, bringing `pristine-tar` from the dead seems like a terrible idea
for pkg-go, for reasons that have been already explained at length both
in the present discussion and back in 2017.
So, all in all, I would support a proposal that:
1. Recommends `wrap-and-sort -tsa`, along with changes in default
settings for dh-make-golang.
2. Recommends switching to the `upstream/*` namespace for following
upstream branches, to ease tracking different upstream repositories,
repackaging commits, etc. A tool to automate this switch would go a long
way towards adoption.
Note that DEP-14 -as well as git-buildpackage- does not care about these
branches, as only upstream/* tags are used during builds.
My 5¢.
--
Martina Ferrari
Reply to: