As an upstream developer of software in Debian, my personal recommendation is that you don’t do the Debian packaging in your upstream repository. I host my own git instance with my upstream code here: https://gitweb.stoutner.com/?p=PrivacyBrowserPC.git;a=summary I have a Salsa repository with the Debian packaging here: https://salsa.debian.org/soren/privacybrowser There are a lot of advantages to hosting the packaging in Salsa, including Salsa CI. https://salsa.debian.org/salsa-ci-team/pipeline Which produces the following: https://salsa.debian.org/soren/privacybrowser/-/pipelines/852997 I also use the git-buildpackage structure for my Salsa repository. Explaining all of what that means is beyond the scope of this email, but there is a brief explanation of how that makes my life easier here: https://lists.debian.org/debian-mentors/2024/09/msg00057.html
Thanks a lot for this advice. I like this separation as well, but
originally kept them together because I release standalone deb
files as well. The Debian packaging workflow that I have was
designed to serve this purpose, not uploading it to official
Debian repos. Now that I have an ITP, I'll consider moving to
Salsa-based packaging if it isn't too disruptive.
(The deb files I mentioned are for different versions of Ubuntu,
built on the corresponding ones. I'm used to the PPA workflow and
Vara is already on the Snap store, but there are users who expect
it to be delivered as deb files.)
-- Nandakumar Edamana https://nandakumar.org