Use DEP-14 branch names debian/latest and upstream/latest, and upstream vcs remote name 'upstreamvcs'

[ottok]

See commits for details. This is a re-submission of #225, pending to be merged potentially in the summer of 2025.

[umlaeute]

except a misinterpretation of DEP-14

how's debian/latest a misinterpretation? i fully acknowledge that DEP-14 allows different names, and that there is controversy about which name to pick and that otto is pushing rather this controversial name strongly. but nevertheless is debian/latest is explicitly suggested (among others) by DEP-14, so it's a valid interpretation.

[guillemj]

What is a misinterpretation is stating the debian/latest is the preferred branch name by the DEP, which is not true.

[ottok]

I did not invent debian/latest or upstream/latest, they are from DEP-14. I have however been using them successfully for many years and I think they make sense. Personally I would feel odd if I was using a branch called debian/unstable as the permanent default branch in git and the development branch, and occasionally uploading to experimental from a branch called 'unstable'. The reason DEP-14 (which I didn't write) recommends debian/latest is presumably to avoid mixing up default git branch name with the target archive name.

[NightTsarina]

I did not invent debian/latest or upstream/latest, they are from DEP-14. I have however been using them successfully for many years and I think they make sense. Personally I would feel odd if I was using a branch called debian/unstable as the permanent default branch in git and the development branch, and occasionally uploading to experimental from a branch called 'unstable'. The reason DEP-14 (which I didn't write) recommends debian/latest is presumably to avoid mixing up default git branch name with the target archive name.

@ottok Here lies the problem:

1. DEP-14 does not mandate debian/latest, debian/<suite> is also a valid option.
2. The team does not use debian/unstable for uploads to experimental, but debian/experimental.
3. Despite your experience, the go-team has been using DEP-14 successfully for many years, and there is absolutely no benefit in this change, but a huge cost.

[rhansen]

As an outsider, this PR looks good to me.

I didn't see any specific objections to changing upstream to upstream/<something>, or to changing the upstream remote name to uptreamvcs. Maybe just those changes (but with upstream renamed to upstream/sid for consistency with debian/sid?) would be less controversial?

1. DEP-14 does not mandate debian/latest, debian/<suite> is also a valid option.

DEP-14 mentions debian/latest first, so I suspect many packages outside of the Go team will (or already do) use debian/latest. It would be nice if all repos were consistent, otherwise why bother with DEP-14 at all?

Also, DEP-14 says, "we recommend the <vendor>/<suite> scheme over <vendor>/<codename>". If the Go team doesn't want to use debian/latest, I would expect dh-make-golang to use debian/unstable instead of debian/sid. Changing this alone is probably not worthwhile, but if upstream is going to be renamed to upstream/<something> then it might be a good opportunity to align with the recommendation.

(FWIW, I think DEP-14 is too weak, and that it should instead take an unambiguous opinionated stance. If the strict guidelines wouldn't work well for a particular package then that package's maintainer can choose to not conform with DEP-14.)

3. Despite your experience, the go-team has been using DEP-14 successfully for many years, and there is absolutely no benefit in this change, but a huge cost.

Some benefits:

• consistency that tooling can depend on
• less surprising behavior for potential maintainers that are expecting debian/latest

I'm not familiar with all of the Go team's tooling, so I'm curious to know why renaming upstream/sid to upstream/latest would be a "huge cost". I would expect incremental adoption to be feasible option: a new repo would use the new branch name, while an existing repo would continue to use the old branch name until someone felt like renaming it.

(Renaming a published branch causes disruption in existing Git clones, but I think it's reasonable to assume that package maintainers are competent Git users and can easily deal with the disruption. If that's too generous, a script can help with the tricky bits.)