Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

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

wants to merge 2 commits into from

Conversation

ottok
Copy link
Contributor

@ottok ottok commented Feb 19, 2025

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

NightTsarina
NightTsarina requested changes Feb 19, 2025
View reviewed changes
Copy link
Contributor

@NightTsarina NightTsarina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the changes in this PR are not very controversial and I support them, even if I personally prefer upstream/<upstream HEAD> instead of upstream/latest (which is valid DEP-14 as we are not importing tarballs but following git history.

But big NACK to the change of the debian branch, you still haven't given a reason to change, except a misinterpretation of DEP-14. This PR cannot be merged until there is a consensus on this topic.

@umlaeute
Copy link

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
Copy link
Contributor

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

@ottok
Copy link
Contributor Author

ottok commented Feb 21, 2025

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
Copy link
Contributor

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.

ottok added a commit to ottok/dh-make-golang that referenced this pull request May 14, 2025
@ottok
WIP Debian#247 @ 8710283
bbe534f
ottok added a commit to ottok/dh-make-golang that referenced this pull request May 14, 2025
@ottok
WIP Debian#247 @ 8710283
f3b05ae
@ottok ottok force-pushed the fix-branch-names branch from 8710283 to d0c9d21 Compare May 15, 2025 19:22
ottok added a commit to ottok/dh-make-golang that referenced this pull request May 15, 2025
@ottok
WIP Debian#247
cc5ad87
ottok added 2 commits August 20, 2025 15:03
@ottok
Use DEP-14 branch names debian/latest and upstream/latest
5bcc117 
In DEP-14, the preferred branch name for the Debian packaging target
branch is `debian/latest` and the preferred name for the upstream import
target branch is `upstream/latest`.

Note that the upstream development branch name can be whatever and
should stay as it is upstream, typically `main` or `master`. The branch
`upstream/latest` should not point to the latest upstream development
commit, but to the latest commit that was used as the upstream release
that the Debian revision was derived from.
@ottok
Always call upstream git remote upstreamvcs
3ead601 
Instead of using various different upstream remote names, use the one
and same upstream git remote name consistently. As the name pick
`upstreamvcs` just as git-buildpackage does, so that if anybody runs
`gbp clone` they will automatically end up with the same git remotes and
branches as anyone in to go-team.
@ottok ottok force-pushed the fix-branch-names branch from d0c9d21 to 3ead601 Compare August 20, 2025 22:05
@rhansen
Copy link

rhansen commented Sep 27, 2025

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@NightTsarina NightTsarina NightTsarina requested changes

Requested changes must be addressed to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@ottok @umlaeute @guillemj @NightTsarina @rhansen