|
|
|
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.
|
|
|
|
|
|
|
|
Furthermore 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`).
|
|
|
|
Packages that only ever being uploaded to `unstable` will have only `master` branch so there is no need to customise default _git_ branch for all package repositories.
|
|
|
|
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:
|
|
|
|
|
|
|
|
```
|
|
|
|
# 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.
|
|
|
|
|
|
|
|
# Team member needs to find the upstream git repository - "{gitrepoRL}".
|
|
|
|
# Then
|
|
|
|
git remote add upstream {gitrepoRL}
|
|
|
|
git fetch upstream
|
|
|
|
git checkout upstream
|
|
|
|
git branch --set-upstream-to=origin/upstream
|
|
|
|
git merge upstream/master
|
|
|
|
git tag upstream/1.11.0 v1.11.0
|
|
|
|
git checkout master ## or "debian/sid" as proposed in DEP-14.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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. |
|
|
\ No newline at end of file |
