[PureOS] Updating localechooser in landing/byzantium

[Carsten Schoenert]

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:
> 
>   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 at 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.

-- 
Regards
Carsten Schoenert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20211008/71ec25bd/attachment.sig>