Re: Best practices for Debian developers who are also upstreams?
Hello!
Currently the project where I am closest to this goal is in
rdiff-backup. The upstream debian/ is almost 1:1 to the downstream
debian/. I've made a dh_gencontrol override to ensure the upstream CI
always builds binaries with the correct version number inherited from
a git tag in upstream:
https://github.com/rdiff-backup/rdiff-backup/blob/master/debian/rules
What remains is to decide what to do to the debian/changelog. The
version there still leaks the source package version number that ends
up in *.changes and *.dsc..
Otherwise it is rolling pretty well. The upstream .travis-ci.yml
builds the .eb just like Debian will eventually do (apart from some
version and changelog differences) and all bugs I encounter in Debian
or elsewhere can be fixed directly on upstream for everybody's
benefit. My work on the quality of the software is directly beneficial
at upstream and "globally" and not just for Debian. I still have a
separate Debian repo on salsa.debian.org but in future I think I'll
have a debian/master branch directly in upstream repository and
configure to git-buildpackage the upstream branch as 'master'.
One of the best inspirations for this was
https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging and
examples at https://github.com/vincentbernat/pragmatic-debian-packages/tree/master
but I am still looking to optimize the process as a whole.
I don't feel there is any problem with "two hats". Pretty much
everything the Debian policy states about software quality applies
universally to any open source project. The things that are very
Debian specific will only be expressed in code under debian/ and not
affect other distros. If this works out well I'll expand to become
upstream in all projects I maintain in Debian if the upstreams trust
me enough to give write access. The closer a maintainer is to the
upstream, the better everything will be I reason.
- Otto
Reply to: