[PureOS] Updating localechooser in landing/byzantium

Sat Oct 9 01:25:20 PDT 2021

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%2Flatest

(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.

-- 
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/20211009/eb161d02/attachment.sig>