If you are interested, then I do have suggestions on how to try keep both qualities small - i.e. semi-automated routines - but they evolve around a core principle of treating the parent source (Debian) as the primary and PureOS getting applied on top.

When you do a git merge then changelog files are meshed, and when you follow "strategy b)" you don't. That seems rather consequential to me, not orthogonal.

@evangelos.tzaras: Is the issue you reported here broadly about any and all best any practice(s) in PureOS missing or undocumented?

I would love to have https://tracker.debian.org/ also link to PureOS patches - and I see how that is doable by parsing Debian Policy standards-compliant source packages and look for DEP-5 standards-compliant patches. Which standards should I follow to implement such feature for git branches/commits?

I could've maybe worded it more clearly in the OP: I was mostly concerned with how to update packages - especially when we're a downstream of Debian.
The question arose because of T1048 and the discussion that ensued around how d/changelog should look like.

I was mostly confused whether this would imply that we would have both pureos/latest and pureos/byzantium.

For the record, this very issue report was not meant as "this package is totally WRONG" - which is the reason I marked it as severity normal.

I propose to reframe this issue to say "best practice(s) is missing/undocumented".

I opened https://tracker.pureos.net/T1049 for the meta discussion and will leave this open until the meta-issue has been clarified (as you suggested)

Rebasing? In the git sense of the word? Wouldn't that imply having to always force push to our packaging repositories (which would destroy/rewrite the git history)?

So would that be pureos/latest (instead of pureos/byzantium) and pureos/amber or pureos/amber-phone then?
Confusing!

Feel free to delete my draft which arouse out of confusion around the Uploaders: field ;)

i was just wondering under which circumstances i would use dput?
my understanding was that when pushing a signed tag in the packaging repos (those which are pointed to from deb-build-jobs (?)) that the build server would automagically start the build.