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
