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)?

I was under the impression (I might be wrong!) that my workflow of merging the latest debian tag was the current practice, see f.e. https://source.puri.sm/Librem5/debs/pkg-phosh/-/commits/pureos/byzantium and the resulting changelog https://source.puri.sm/Librem5/debs/pkg-phosh/-/blob/pureos/byzantium/debian/changelog

Please keep packaging close to its parent, by rebasing changes on top of latest Debian package release.

@jonas.smedegaard Can you define close here? Close as in 'pureos changes should be close to the branch head' ?

Can you link to the official packaging docs that document how a downstream fork comes to live and is long term maintained using this rebasing workflow? Is that 'rebasing' a recommendation or a must? https://tracker.pureos.net/w/development/packaging_overview/ does not talk about that and looking at https://source.puri.sm/Librem5/gnome-initial-setup (and some other packages) it seems merging in Debian's git is a common pattern and that's also what the Librem 5 does in the packages i came across. It's also what matches the 'backporting/downstreaming' patterns people come to think in.

I use git lingo, yes, but I am talking about .deb packaging which at its core is not git-based: Git and onther VCSes are merely an aid in handling the file-based package maintenance - where it certainly is extra helpful when both Debian and PureOS preparations are done using compatible VCS tools and routines.

You need not force-push to rebase PureOS changes on top of HEAD of Debian package maintenance: See the `git merge --strategy ours part of https://source.puri.sm/pureos/packages/firefox-esr/-/blob/pureos/esr60/master/debian/README.source for an example.

Please do not expand this issue to become a meta discussion about what is common and what is uncommon: That is quite important to figure out but as separate issues.
If you are uncertain if this is a waste of time to deal with due to it being the "wrong" way to maintain packages in PureOS then I recommend to simply leave it open until that other meta-issue has been clarified.
If instead you are certain that this is wrong, then close this issue as wontfix - with your reasoning.

Can you define close here?

I can describe it, then maybe we can try define it together.

A package changelog containing parent entries as-is with fork entries alll on top of that is closer to the parent changelog
than a changelog containing parent entries interleaved with fork entries.

I see how my talking in git lingo is confusing here. Sorry!

This issue is about the .deb package released into PureOS - it is not really about how that package was prepared in git, that is just speculations on my part on why the resulting package had interleaved parrent and fork entries in the changelog file.

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)

Please do not expand this issue to become a meta discussion about what is common and what is uncommon: That is quite important to figure out but as separate issues.

It's not meta. It's about trying to find a criteria in the absence of any other authoritative source and to find consensus how to handle that so we don't discuss this same thing again and again for other packages.

A package changelog containing parent entries as-is with fork entries alll on top of that is closer to the parent changelog

than a changelog containing parent entries interleaved with fork entries.

So like

gnome-calls (0.3.2-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos2) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.2-1) experimental; urgency=medium
gnome-calls (0.3.0-2) experimental; urgency=medium
gnome-calls (0.3.0-1) experimental; urgency=medium
...

?

A common ground could be to repeat the changes in the top most changelog entry: https://source.puri.sm/pureos/core/gnome-initial-setup/-/blob/pureos/master/debian/changelog#L18

It's not meta.

Perhaps I use the word wrong. What I mean to say is that it is lesser specific, more abstract - i.e. that "find a criteria in the absence of any other authoritative source and to find consensus how to handle that" is not specific to this package but general to PureOS packaging.

Imagine we reach a conclusion to "find a criteria in the absence of any other authoritative source and to find consensus how to handle that" - does that mean we can close this issue report? No. That is my point.

So like

gnome-calls (0.3.2-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos2) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.2-1) experimental; urgency=medium
gnome-calls (0.3.0-2) experimental; urgency=medium
gnome-calls (0.3.0-1) experimental; urgency=medium

?

No, like these:

gnome-calls (0.3.0-2pureos2) byzantium; urgency=medium
gnome-calls (0.3.0-2pureos1) byzantium; urgency=medium
gnome-calls (0.3.0-2) experimental; urgency=medium
gnome-calls (0.3.0-1) experimental; urgency=medium

gnome-calls (0.3.2-1pureos1) byzantium; urgency=medium
gnome-calls (0.3.2-1) experimental; urgency=medium
gnome-calls (0.3.0-2) experimental; urgency=medium
gnome-calls (0.3.0-1) experimental; urgency=medium

Showing 2 examples to examplify how a) multiple consecutive PureOS releases should be listed individually, but b) whenever sync'ing with Debian all prior PureOS releases should not be listed - instead the remaining pieces from those releases (if any was carried over in the sync'ing process) would be included in the new release.

Point is that each release should briefly explain the changes compared to previous release.

For Debian packages, there are no forking and resync'ing going on, so the changelog naturally behaves like a "log" - but when "meshing" multiple sources together, the arguably more natural thing to do is to mesh the log as well, which in my opinion is plain wrong and leads to a useless changelog file.

Concretely, I am unable to tell from reading the changelog file for gnome-calls if that package is a simple backport from Debian or if it also contains some added features or bugfixes not yet forwarded to Debian.

For reference, Debian Policy v4.5.1 § 4.4 says:

Changes in the Debian version of the package should be briefly explained

For Debian packages, there are no forking and resync'ing going on, so the changelog naturally behaves like a "log" - but when "meshing" multiple sources together, the arguably more natural thing to do is to mesh the log as well, which in my opinion is plain wrong and leads to a useless changelog file.

You have similar patterns in within Debian LTS and backports and I've seen this style being used in both projects, e.g. https://metadata.ftp-master.debian.org/changelogs//main/k/kicad/kicad_5.1.9+dfsg1-1~bpo10+1_changelog . LTS is a bit more 'pathological' since the upstream version *usually* doesn't change but backports is very similar to what we do in PureOS.

Concretely, I am unable to tell from reading the changelog file for gnome-calls if that package is a simple backport from Debian or if it also contains some added features or bugfixes not yet forwarded to Debian.

that's a valid point and I that's exactly why one usually repeats remaining changes in the topmost entry. I also consider having all ever released to pureos version in the changelog an upside since it tells me at a glance that this isn't a new thing (which is informaton you use otherwise).

I don't know rules for LTS, but the semi-official (i.e. officially .org hosted but officially unsupported) backports.debian.org seems to a) recomend including all changes compared to newest parent release in topmost changelog section(s):

It is recommended to include all changelog entries since the last version on debian-backports or since stable if it's the first version. You should do this by passing "-v" to dpkg-buildpackage. Eg: "debuild -v0.7.5-2", where "0.7.5-2" is the version in stable.

...and b) tolerate but discourage injecting/preserving interleaved sections for prior forks:

Backports of an updated version of a package that was backported before may have a changelog that merges entries of backports of previous versions, but this is not required.

(emphasis theirs!)

Not recommending interleaved sections for prior forks is (in my view) aligned with their more general rule of keeping changes to a minimum:

Keep the diff between the testing and the backports versions as minimal as possible.

Above quotes taken from https://backports.debian.org/Contribute/#index3h2

It would make sense to me that PureOS borrows the above quoted phrases (adapted to replace "backport" with "fork", obviously).

Backports of an updated version of a package that was backported before may have a changelog that merges entries of backports of previous versions, but this is not required.

i don't read that as discourage but rather as 'don't bother' and that's fine with me since it covers both cases (what @evangelos.tzaras used and what you had in your example).

It is recommended to include all changelog entries since the last version on debian-backports or since stable if it's the first version. You should do this by passing "-v" to dpkg-buildpackage. Eg: "debuild -v0.7.5-2", where "0.7.5-2" is the version in stable.

This is about what ends up in the *changes* file for the upload, not the changelog entry.

But then again it's fine for me have a sensible summary in the topmost changelog entry but i'd also not make that a requirement *if* the package is git backed.

This is about what ends up in the *changes* file for the upload, not the changelog entry.

Ah, right. Seems I was reading too much of my own opinion into that :-)

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.
Similarly, I was not (in my wishful thinking) reading into those quoted backports.debian.org phrases that they should become mandatory requirements, only recommentation and discouragement.

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.

Don't worry, that's not how I understood it :)

Reading through the discussions was definitely interesting and thought provoking!

PS: Going forward I'm happy to follow whatever the consensus ends up being :)