Use DEP-14 branch names debian/latest and upstream/latest, and upstream vcs remote name 'upstreamvcs'#247
Use DEP-14 branch names debian/latest and upstream/latest, and upstream vcs remote name 'upstreamvcs'#247ottok wants to merge 2 commits intoDebian:masterfrom
Conversation
NightTsarina
left a comment
NightTsarina
left a comment
There was a problem hiding this comment.
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.
how's |
|
What is a misinterpretation is stating the |
|
I did not invent |
@ottok Here lies the problem:
|
ottok
force-pushed
the
fix-branch-names
branch
from
d0c9d21 to
3ead601
Compare
|
As an outsider, this PR looks good to me. I didn't see any specific objections to changing
DEP-14 mentions Also, DEP-14 says, "we recommend the (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.)
Some benefits:
I'm not familiar with all of the Go team's tooling, so I'm curious to know why renaming (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.) |
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.
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
force-pushed
the
fix-branch-names
branch
from
3ead601 to
9769152
Compare
Yes this is intentionally a suggestion for the Go team to start using |
I agree with @NightTsarina that the cost is huge, for almost no benefit. This will introduce even more fragmentation between the repositories of the team. IMO in the team, package consistency is much more important than following latest recommendations. And introducing a new change will never replace the previous style on all packages, so it will only create more and more fragmentation. IMO for such a disruptive change, it has to have a very obvious advantage. I still fail to see the concrete advantage this change provides.
It is not just this that needs to be updated, it is all the repos cloned by everybody everywhere. Once again, for almost no benefit.
There will still be some places where one would have to know the branch and will have to check what is the layout used by a package, like basic git checkout. |
If the latest recommendations can't be followed out of concern for inconsistency, then they're not recommendations—they're "wouldn't it be nice if" wishful thinking. Any procedure change is going to cause some inconsistency. If inconsistency is strongly discouraged, then it becomes very difficult to make any procedure changes. Without procedure changes we can't make important improvements. I think it's better for the Debian Go team to just accept some inconsistency as the cost of making progress. Our tools will have to be written to accommodate the inconsistency. When the inconsistency is minor (like this PR), we humans are smart enough to deal with it, and modify our tools to deal with it if necessary. When it's major, we can create new tools to automate bulk changes across all projects, or at least flag the problems for manual correction. As @ottok says, the costs are not high. We already have to deal with different branch names in different repositories, so I don't believe the inconsistency argument. And there's no need to update existing repos, so that's not a cost either.
Some benefits:
|
6 participants
See commits for details. This is a re-submission of #225, pending to be merged potentially in the summer of 2025.