Hi,
I've looked at localechooser as it's mentioned currently in the synchronization issues for landing.
https://master.pureos.net/sync/landing
Last time the package was touched was in 2018 by Matthias and shortly later by Chris [1]. As Matthias choose to start with a standalone branch back in 2018 I now merged the Debian tag 2.93 from the upstream repository on Salsa into a derived branch pureos/latest based on the standalone branch named master within the Purism tree. That's how I see future work will be manageable, merging the required Debian tag into the derived PureOS tree as done in other forked repos. I managed to get the merge conflicts solved so far.
I also added a configuration for gbp and also a CI controlling file.
So why I'm posting here? Simply because there is no target branch on the destination tree I can create a MR for and also because I'm currently not know much about the background for this forked package.
So please have a look at the current state I prepared [2] for further discussion. The CI pipeline succeeded so far. But as for python-apt, other things might be needed to check before pushing my work to the main repo.
[1] https://source.puri.sm/pureos/core/localechooser [2] https://source.puri.sm/carsten.schoenert/localechooser/-/commits/pureos/late...
Quoting Carsten Schoenert (2021-10-06 14:32:00)
I've looked at localechooser as it's mentioned currently in the synchronization issues for landing.
https://master.pureos.net/sync/landing
Last time the package was touched was in 2018 by Matthias and shortly later by Chris [1]. As Matthias choose to start with a standalone branch back in 2018 I now merged the Debian tag 2.93 from the upstream repository on Salsa into a derived branch pureos/latest based on the standalone branch named master within the Purism tree. That's how I see future work will be manageable, merging the required Debian tag into the derived PureOS tree as done in other forked repos. I managed to get the merge conflicts solved so far.
I also added a configuration for gbp and also a CI controlling file.
So why I'm posting here? Simply because there is no target branch on the destination tree I can create a MR for and also because I'm currently not know much about the background for this forked package.
So please have a look at the current state I prepared [2] for further discussion. The CI pipeline succeeded so far. But as for python-apt, other things might be needed to check before pushing my work to the main repo.
[1] https://source.puri.sm/pureos/core/localechooser [2] https://source.puri.sm/carsten.schoenert/localechooser/-/commits/pureos/late...
Interesting case, Carsten. Thanks for bringing it up here!
Purism work can be tricky because it intermixes upstream and downstream work - i.e. Purism is sometimes upstream of e.g. Debian and GNOME, and sometimes Purism is downstream to them, even for same code projects.
Purism has an "upstream first" mantra. To me that translates generally as "commit upstream work directly to upstream repos (don't wait for upstream to cherry-pick from some downstream repo)".
Purism customers have higher priority than the "upstream first" mantra, however: In cases where pushing urgent changes upstream would delay getting them into Purism products, Purism customers take precedence.
(sorry if above is obvious to you - took some time for me to align it)
The previous PureOS packaging of localechooser seems weakly aligned with upstream: It tracked upstream _tarball_ source but not upstream _git_ development.
Maybe the reason was to quickly serve Purism customers back then. Assuming we are not in a similar hurry now, this seems a good time to switch to use the "upstream first" mantra for this packaging work.
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:
1. 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
2. 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
3. rewind to closest possible upstream commit before or at their latest release:
git reset --hard 2.93
4. auto-generate² boilerplate forking commits:
~/projects/PURISM/FEATURE/package/bin/fork_at_pureos_for_byzantium.sh
5. cherry-pick non-boilerplate commit from previous work:
git cherry-pick 87c1922826060102a2d5a9abe968dc657630fab9
6. 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
¹ Others in Purism do differently, treating _both_ Debian and PureOS timelines as parallel "baselines", merging them when needing to realign with Debian, but I find that such "multiverse" of multiple timelines has higher risk of breaking in subtle maybe unnoticed ways and therefore less reliably tracks atomic commits to pass upstream, and find it cumbersome to compose a meaningful changelog for our users from such multiverse structure. See https://tracker.pureos.net/T1049 for discussion on changelog style (which often reflects underlying git structure as well).
² My approach is also documented - with details on steps 4 and 6 - at https://source.puri.sm/-/snippets/1165#fork-for-pureos
- Jonas
Hi Jonas,
Am 07.10.21 um 13:36 schrieb Jonas Smedegaard: ...
Purism work can be tricky because it intermixes upstream and downstream work - i.e. Purism is sometimes upstream of e.g. Debian and GNOME, and sometimes Purism is downstream to them, even for same code projects.
yes, it's quite always the upstream source that is different for thess two use cases. The steps to keep upstream tracked is basically the same I'd say.
Purism has an "upstream first" mantra. To me that translates generally as "commit upstream work directly to upstream repos (don't wait for upstream to cherry-pick from some downstream repo)".
Purism customers have higher priority than the "upstream first" mantra, however: In cases where pushing urgent changes upstream would delay getting them into Purism products, Purism customers take precedence.
(sorry if above is obvious to you - took some time for me to align it)
:) That's the usual way and I understand this. Costumers pay money for products, and money is needed to get my work payed.
The previous PureOS packaging of localechooser seems weakly aligned with upstream: It tracked upstream _tarball_ source but not upstream _git_ development.
Maybe the reason was to quickly serve Purism customers back then. Assuming we are not in a similar hurry now, this seems a good time to switch to use the "upstream first" mantra for this packaging work.
That's what I was thinking about, how to get this without loosing all or most of the history. Within localechooser there isn't much that would make it that difficult.
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 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.
To get the Debian source integrated the PureOS related branch needs to get renamend first (I'd use "pureos/latest") and pushed, afterwards the old master branch can be removed by the UI.
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.
But the way Jonas has described is also possible. :) I don't think one way is easier or quicker than the other so it's mostly a choice of preference.
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
Hello Jonas,
I don't wanted to start a discussion challenge that costs a lot of time on all sides and wasn't a big movement forward until now, at least for me. My last week of holidays is over now and I wont have that much time working further on this. I was hoping I can get updated that rather small and easy package localechooser the past week.
So I'd like to only give some partial notes and comments.
Am 08.10.21 um 11:13 schrieb Jonas Smedegaard:
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.
We will find for sure 3-5 other possible ways to reach the goal, and they all will have ups and down depending on the PoV each of us. We all have different workflows we learned and practice over the years and will mostly prefer the one we use for long times because we now it working. The user in the end doesn't cares much about how "his" package was build or derived, for me as an part time contributor it's important I can spend my time most efficiently.
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
After reading this quite longer discussion from T1049 I still see no gain for me for doing something different than 'git merge' to manage upstream changes. It's possible yes, but I for my self wont be able to do this for time and complexity reasons e.g. for Thunderbird where I need to keep track of all possible releases right now (exp -> sid -> stable -> old-stable). Preparing and doing a Debian release is now almost work for about 8h including some testing, so I'm glad that git helps me if I do a 'git merge' into the next logical release and I mostly only need to reorder d/changelog.
...
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.
That's correct if you only work by merging tags. But does not really help to get and use a common practice that keeps the barrier low for newbies (like currently me) and maintenance time burden and complexity at a minimum if we do it differently all over. OTOH a name clashing wouldn't exist if name spaces would be used, And more, for me is working with (local) branches more intuitive than only working with tags. And of course I need some graphical tools like gitk, gitg to get an logical overview. Within Debian there are teams and packages that are using the upstream git tree instead of using gbp "only" for importing tarballs and managing Debian patches, there it's essential that different branch names are used. And we are now in a comparable situation I think.
In the end I (want to) see no difference if I work within a Debian packaging tree directly or in a PureOS tree, it's all just another fork I'm working in. Just that PureOS is here a fork of the Debian source, while Debian is technically also just a fork of upstream. Why should I (we) work differently then?
...
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).
...
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.
We starting to go in circles, and we're back on the starting point...
So now after some rounds of discussion I see one main question were we should come to an common answer as this is the ground for potential further work from me.
What to do with git trees which currently don't use DEP14 for branch names?
My guess is that all participants agree that we want to use a "pureos/" prefix within PureOS related work as already pointed in T1049, the question to me is how to migrate the existing trees/repos?
My preference on doing that is currently to create the branch "pureos/latest" based on HEAD of (origin≙pureos) "master" with a deletion of the old master branch by the GitLab UI afterwards. Then adding and merging in the Debian/Salsa source (which might contain a branch named "master") with possible additional PureOS related commits on top.
For localechooser this would look like this:
https://source.puri.sm/pureos/core/localechooser-test/-/network/pureos%2Flat...
(To see where are caveats like required permissions I've setup the -test repo within /pureos/core/).
To get things done I'd like to postpone the topic 'git merge' vs. 'git rebase' into the future for now. Otherwise I fear we wont get any further.
...
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
That is unfortunately correct. :( I wasn't aware that there was already a lollypop tree until now. Then we need to think about how get that split fixed.
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.
As written above, I see no real gain in doing so.
Quoting Carsten Schoenert (2021-10-09 10:25:20)
I don't wanted to start a discussion challenge that costs a lot of time on all sides and wasn't a big movement forward until now, at least for me. My last week of holidays is over now and I wont have that much time working further on this. I was hoping I can get updated that rather small and easy package localechooser the past week.
Sorry, I mistook your original post as asking for best practice.
I understand now that you were instead asking for simplest practice.
Am 08.10.21 um 11:13 schrieb Jonas Smedegaard:
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.
We will find for sure 3-5 other possible ways to reach the goal, and they all will have ups and down depending on the PoV each of us.
We all have different workflows we learned and practice over the years and will mostly prefer the one we use for long times because we now it working.
For the record, the method I use is not old habit, but evolved recently to handle the complexities of maintaining forks of Debian.
Good luck with the `git merge` approach.
- Jonas
-
Carsten Schoenert -
Jonas Smedegaard