| ... | ... | @@ -115,10 +115,23 @@ That happened because someone renamed branch `master` to `debian/master`... :( |
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Another minor yet annoying problem is how upstream files are merged with
|
|
|
|
"debian/" files (unrelated to branch naming). When "upstream" follows
|
|
|
|
upstream git repository, a simple merge can throw hundreds of commits into
|
|
|
|
git history in between commits to "debian/" files. As maintainer, I need to
|
|
|
|
see what other co-maintainers were doing, not the extensive history of
|
|
|
|
upstream changes that floods and dilutes relevant history of changes to
|
|
|
|
packaging. Although one can filter those changes by `git log debian` or
|
|
|
|
`gitg debian` it is inconvenient when it is necessary to do so.
|
|
|
|
Having packaging history segregated from upstream history is helpful.
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
Few other things are worth noticing:
|
|
|
|
|
|
|
|
DEP-14 is too difficult for MUT packages.
|
|
|
|
|
|
|
|
DEP-14 is not universally suitable to produce a release tarball.
|
|
|
|
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
|
| ... | ... | @@ -128,15 +141,18 @@ 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
|
|
|
|
repository. Why merging 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.
|
|
|
|
worst. Is this really a "one size fits all" argument?
|
|
|
|
|
|
|
|
DEP-14 is a distraction. Packaging for Debian is difficult enough to
|
|
|
|
religiously adhere to a very specific repository layout that fits one
|
|
|
|
religiously adhere to a very specific repository layout to satisfy 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?
|
|
|
|
repository layout is not. Maintainers should care for "uscan" and
|
|
|
|
"debian/watch" for correct fetching of new upstream releases. There is less
|
|
|
|
incentive to care about those things when tarball is generated from the
|
|
|
|
repository.
|
|
|
|
|
|
|
|
Contributors comfort and ergonomic matter. We should not fight each other
|
|
|
|
workflows. Effective team collaboration is when people work together
|
| ... | ... | |
