|
|
|
I object to [DEP-14](https://dep-team.pages.debian.net/deps/dep14/) which is pushing all the wrongdoings of [GBP](no-gbp) even further.
|
|
|
|
|
|
|
|
IMHO branch names should derive from [distribution](https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-distribution) field in _changelog_ (e.g. `experimental`, `unstable`, `stretch-backports`, etc.) with only exception where `master` branch is targeting `unstable` distribution (because `master` is the default _git_ branch for most uploads to `unstable` -- the default upload suite).
|
|
|
|
For packages that only ever uploaded to `unstable` it is enough to have just `master` branch so there is no need to customise default _git_ branch for all package repositories.
|
|
|
|
|
|
|
|
Re-naming default branch `master` to `debian/sid` is _harmful_ as it achieves nothing yet requires significant adjustments in public repositories, GtiLab project settings as well as to maintainers' local repositories and habits.
|
|
|
|
|
|
|
|
Intention of DEP-14 appears to be clear: to segregate "debian/*" packaging bits and upstream branches in their own name space within one git repository. On the surface it makes sense: why importing upstream "master" branch into "upstream" branch of the downstream repository? If we move debian-maintained portions into `debian/` branches then Debian packaging can co-exist within the upstream repository or be added to the clone of the upstream repository.
|
|
|
|
|
|
|
|
So DEP-14 is _only_ useful when upstream maintains Debian packaging outside of Debian or when upstream git repo is mirrored by Debian maintainers with intent to maintain Debian packaging segregated from upstream branches. The latter have undesirable overhead and disadvantages.
|
|
|
|
|
|
|
|
Some time ago Golang community refused to listen to reason and resisted to version libraries. The problem was common and back then it was difficult to generate upstream tarball so it made some sense to add upstream git repository as "git remote", `fetch` and `merge` it to _upstream_ branch then tag to produce a tarball. However these days Golang community much improved and most libraries are tagged and versioned. In most cases obtaining upstream tarballs has become trivial.
|
|
|
|
|
|
|
|
For packages that have no difficulties to obtain upstream tarball, DEP-14 yields no benefits.
|
|
|
|
Importing upstream tarball to `upstream` branch is easy as it requires merely two commands: `uscan` (or `origtargz`) followed by `gbp import-orig`. But in my experience there is nothing worse than situation when `upstream` branch follows upstream repository.
|
|
|
|
|
|
|
|
The problem is due to difficulties importing new upstream release. Consider the following example:
|
|
|
|
I object to [DEP-14](https://dep-team.pages.debian.net/deps/dep14/) which
|
|
|
|
is pushing all the wrongdoings of [GBP](no-gbp) even further.
|
|
|
|
|
|
|
|
IMHO branch names should derive from
|
|
|
|
[distribution](https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-distribution)
|
|
|
|
field in _changelog_ (e.g. `experimental`, `unstable`, `stretch-backports`,
|
|
|
|
etc.) with only exception where `master` branch is targeting `unstable`
|
|
|
|
distribution (because `master` is the default _git_ branch for most uploads
|
|
|
|
to `unstable` -- the default upload suite).
|
|
|
|
|
|
|
|
For packages that only ever uploaded to `unstable` it is enough to have
|
|
|
|
just `master` branch so there is no need to customise default _git_ branch
|
|
|
|
for all package repositories.
|
|
|
|
|
|
|
|
Re-naming default branch `master` to `debian/sid` is _harmful_ as it
|
|
|
|
achieves nothing yet requires significant adjustments in public
|
|
|
|
repositories, GtiLab project settings as well as to maintainers' local
|
|
|
|
repositories and habits.
|
|
|
|
|
|
|
|
Intention of DEP-14 appears to be clear: to segregate "debian/*" packaging
|
|
|
|
bits and upstream branches in their own name space within one git
|
|
|
|
repository. On the surface it makes sense: why importing upstream "master"
|
|
|
|
branch into "upstream" branch of the downstream repository? If we move
|
|
|
|
debian-maintained portions into `debian/` branches then Debian packaging
|
|
|
|
can co-exist within the upstream repository or be added to the clone of the
|
|
|
|
upstream repository.
|
|
|
|
|
|
|
|
So DEP-14 is _only_ useful when upstream maintains Debian packaging outside
|
|
|
|
of Debian or when upstream git repo is mirrored by Debian maintainers with
|
|
|
|
intent to maintain Debian packaging segregated from upstream branches. The
|
|
|
|
latter have undesirable overhead and disadvantages.
|
|
|
|
|
|
|
|
Some time ago Golang community refused to listen to reason and resisted to
|
|
|
|
version libraries. The problem was common and back then it was difficult to
|
|
|
|
generate upstream tarball so it made some sense to add upstream git
|
|
|
|
repository as "git remote", `fetch` and `merge` it to _upstream_ branch
|
|
|
|
then tag to produce a tarball. However these days Golang community much
|
|
|
|
improved and most libraries are tagged and versioned. In most cases
|
|
|
|
obtaining upstream tarballs has become trivial.
|
|
|
|
|
|
|
|
For packages that have no difficulties to obtain upstream tarball, DEP-14
|
|
|
|
yields no benefits. Importing upstream tarball to `upstream` branch is easy
|
|
|
|
as it requires merely two commands: `uscan` followed by `gbp import-orig`.
|
|
|
|
But in my experience there is nothing worse than situation when `upstream`
|
|
|
|
branch follows upstream repository.
|
|
|
|
|
|
|
|
The problem is due to difficulties importing new upstream release. Consider
|
|
|
|
the following example:
|
|
|
|
|
|
|
|
```
|
|
|
|
# Team member notices that `upstream` branch follows upstream git repository.
|
|
|
|
# How? It is very easy to miss because normally there is no reason to check.
|
|
|
|
# `uscan`, followed by `gbp import-orig` works but disrupts `upstream` branch
|
|
|
|
# causing frustration to maintainer who follows upstream git repo in the "upstream"
|
|
|
|
# branch.
|
|
|
|
# How?? It is very easy to miss because normally there is no reason to check.
|
|
|
|
# `uscan`, followed by `gbp import-orig` works for most packages but disrupts
|
|
|
|
# `upstream` branch if maintainer configured it to follow a certain branch
|
|
|
|
# in the upstream git repository.
|
|
|
|
# Such configuration is local to the clone and not shared which makes it too
|
|
|
|
# easy to cause frustration to maintainer who follows upstream git repo in
|
|
|
|
# the "upstream" branch by accidentally importing release tarball with
|
|
|
|
# `gbp import-orig`.
|
|
|
|
|
|
|
|
# Team member needs to find the upstream git repository - "{gitrepoRL}".
|
|
|
|
# Then
|
| ... | ... | @@ -36,15 +71,16 @@ git merge --squash upstream/1.11.0 |
|
|
|
git commit -a -m "Merge upstream/1.11.0"
|
|
|
|
```
|
|
|
|
|
|
|
|
Note that _every_ contributor have to follow those steps to follow upstream repository.
|
|
|
|
The effort is _ridiculous_. The process is fragile and tedious and manual.
|
|
|
|
Instead of just two (pretty much the same) commands to import tarball to any repository
|
|
|
|
now we have a complicated and unnecessary process making simple update of repository for
|
|
|
|
new upstream release to become needlessly difficult.
|
|
|
|
Note that _every_ contributor have to follow those steps to follow upstream
|
|
|
|
repository. The effort is _ridiculous_. The process is fragile and tedious
|
|
|
|
and manual. Instead of just two (pretty much the same) commands to import
|
|
|
|
tarball to any repository now we have a complicated and unnecessary process
|
|
|
|
making simple update of repository for new upstream release to become
|
|
|
|
needlessly difficult.
|
|
|
|
|
|
|
|
The harms of this are obvious: diversion from focusing on already difficult enough packaging
|
|
|
|
to needlessly complicated redundant and difficult compliance with very particular repository
|
|
|
|
layout.
|
|
|
|
The harms of this are obvious: diversion from focusing on already difficult
|
|
|
|
enough packaging to needlessly complicated redundant and difficult
|
|
|
|
compliance with very particular repository layout.
|
|
|
|
|
|
|
|
**DEP-14 might be a good idea only to small subset of packages but definitely not as default.**
|
|
|
|
|
| ... | ... | @@ -64,9 +100,48 @@ I've found that in most cases having the following branches is enough: |
|
|
|
**Conclusion: DEP-14 creates more problem than it aims to solve.**
|
|
|
|
|
|
|
|
"master" --> "unstable" is an intuitive convention that needs no
|
|
|
|
improvements.
|
|
|
|
Once again (and for the last time hopefully): renaming "master" to
|
|
|
|
"debian/sid" is not worth it.
|
|
|
|
improvements. Once again (and for the last time hopefully): renaming
|
|
|
|
"master" to "debian/sid" is not worth it.
|
|
|
|
|
|
|
|
Some fallout from needless renaming of "master" was already seen:
|
|
|
|
|
|
|
|
```
|
|
|
|
gbp clone git@salsa.debian.org:go-team/packages/golang-github-emicklei-go-restful-swagger12.git
|
|
|
|
gbp:info: Cloning from 'git@salsa.debian.org:go-team/packages/golang-github-emicklei-go-restful-swagger12.git'
|
|
|
|
gbp:error: Git command failed: Error running git checkout: error: pathspec 'master' did not match any file(s) known to git
|
|
|
|
```
|
|
|
|
|
|
|
|
That happened because someone renamed branch `master` to `debian/master`... :(
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Few other things are worth noticing:
|
|
|
|
|
|
|
|
DEP-14 is too difficult for MUT packages.
|
|
|
|
|
|
|
|
Some upstream releases ship software from different name spaces and 3rd
|
|
|
|
party components in the generated release tarballs. For example some Golang
|
|
|
|
developers do not commit "vendor" directory to the repository but include
|
|
|
|
it with tarball releases. Therefore DEP-14 (in a sense of following
|
|
|
|
upstream git repository for the purpose of generating orig tarball for
|
|
|
|
upload) is not suitable for such packages.
|
|
|
|
|
|
|
|
DEP-14 is somewhat redundant. If you are contributing upstream then chances
|
|
|
|
are that you already have a clone of your GitHub fork of the upstream
|
|
|
|
repository. Why smooshing it into public Debian package repository? You can
|
|
|
|
already add multiple remotes to your git repository wherever you like.
|
|
|
|
Mandating it a standard practice is unnecessary at least and harmful at
|
|
|
|
worst.
|
|
|
|
|
|
|
|
DEP-14 is a distraction. Packaging for Debian is difficult enough to
|
|
|
|
religiously adhere to a very specific repository layout that fits one
|
|
|
|
particular build tool. Tarballs releases are important for uploads but git
|
|
|
|
repository layout is not. Is this really a "one size fits all" argument?
|
|
|
|
|
|
|
|
Contributors comfort and ergonomic matter. We should not fight each other
|
|
|
|
workflows. Effective team collaboration is when people work together
|
|
|
|
despite their different preferences. Let's not try to force each other to
|
|
|
|
work in a particular way.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
| ... | ... | |
