[PureOS] Updating localechooser in landing/byzantium

[Jonas Smedegaard]

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/latest/

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: signature
URL: <http://lists.puri.sm/pipermail/pureos-project/attachments/20211007/f8d16c16/attachment.sig>