Quoting Carsten Schoenert (2021-10-08 08:54:58)
Personally¹ I do "upstream first" package maintenance by treating upstream packaging branch as the _only_ baseline, rebasing PureOS commits on top of that when needing to realign with Debian.
I would therefore start over from scratch, starting from upstream Debian git repo. Something like this:
fetch upstream Debian packaging project:
debcheckout localechooser
...or if that fails then locate git and do it manually:
git clone https://salsa.debian.org/installer-team/localechooser.git
include previous work as remote branch _without_ merging:
git remote add pureos_old https://source.puri.sm/pureos/core/localechooser.git git fetch pureos_old
rewind to closest possible upstream commit before or at their latest release:
git reset --hard 2.93
auto-generate² boilerplate forking commits:
~/projects/PURISM/FEATURE/package/bin/fork_at_pureos_for_byzantium.sh
cherry-pick non-boilerplate commit from previous work:
git cherry-pick 87c1922826060102a2d5a9abe968dc657630fab9
finalize¹ and release:
dch --local ~pureos . gbp dch -a DEBEMAIL="jonas.smedegaard@puri.sm" dch --vendor pureos --distribution byzantium --release git commit -m "prepare for release: update changelog" -a
That's the obvious and a straight forwarded way.
I am happy if you find it straightforward. Personally I disagree, though - I find it more straightforward to do `git merge --no-ff 2.93` as step 3, and skip steps 4-5.
I think others also find `git merge` more straightforward - I guess that's the reason they prefer that, and the reason we have the discussion about resulting (to me confusing/misleading) changelog structure at https://tracker.pureos.net/T1049
I was thinking about how we can keep the existing repository and by a bit more manual work to get to the same state in the end. I think it's doable, but with some manual tweaking required within the GitLab UI on source.p.s.
The problem currently is that there are two master branches existing, the one within the localechooser tree and the one on the Debian upstream.
I see no problem there - perhaps I am missing some details?
My approach is to not checkout any Debian branches - and therefore it does not matter if Debian and PureOS use same name for some branch.
Personally I use `tig --all` to browse both local and remote branches together, to locate a commit to rebase from or to cherry-pick. Before I learned about tig I used `git log -p <branch>` for each specific branch (local or remote) I wanted to investigate.
Regardless of my method not affected by potential branch name clash, I agree that we should embrace DEP14 and use branches `pureos/latest` and `upstream/latest` when it does not complicate our collaboration with upstream (I am not aware of any concrete problem, just mean to say that embracing DEP14 should be a "SHOULD" not "MUST" in policy lingo).
The following required steps should be obvious, keep track the Debian sources and do in the end the same as lollypop and seahorse was done, as Guido already mentioned. With the the small exception that I would merge 2.9.3 into the now existing pureos/latest branch. I've all this done locally already.
Sorry, I am not quite sure what you are saying above. It seems that what you describe as "small exception" is what I find an important distinction - and the very reason I described in detail my approach, and tried to provide reasons why.
https://source.puri.sm/pureos/packages/lollypop contains no local feature commits (i.e. no feature changes, only boilerplate changes to packaging metadata) so does not illustrate well how to best tackle package upgrades. What it does illustrate is that it didn't preserve earlier PureOS work - i.e. the work tracked at https://source.puri.sm/librem5-apps/lollypop
https://source.puri.sm/sureos/packages/gnome-boxes illustrates how Chris at debian/3.27.92-1pureos2 created a feature change, and I hundreds of upstream commits later did _not_ do a `git merge` but instead started over (while preserving the old commits tied to their release tag) and cherry-picked the feature change into the fresh fork of upstream work.
- Jonas