[PureOS] Updating localechooser in landing/byzantium

[Jonas Smedegaard]

Quoting Carsten Schoenert (2021-10-16 13:34:27)
> After a week which mostly has consumed all my energy for $dayjob I'm now 
> looking again into solving the original issue.
> 
> Am 09.10.21 um 17:50 schrieb Jonas Smedegaard:
> ...
> >> We can preserve that history in the pureos/packages/lollypop repo 
> >> need be or just leave it as is and use that fork in unlikely case 
> >> we need updates for amber-phone. Both works for me.
> > 
> > That particular work of mine is not important for me that we 
> > preserve.
> > 
> > If topic of this conversation is _simplest_ practice then let's just 
> > throw away historic git repos.
> 
> The lollypop repos are bit out of scope of the original reason for 
> this discussion ... to me it's mostly helpful if I can follow not only 
> a recent development but also past development (if it's not done for 
> pre sarge :P ).
> For sure we can combine the two trees into one were all the PureOS 
> related modification are visible. This would require further work of 
> course.
> 
> So a compromise from a POV of needed effort for me would be to keep 
> the things how they are right now and maybe through away the old 
> amber-phone-stuff after amber has becoming unsupported.
> If I'm feeling boring I can cherry-pick (or someone other) the old 
> changes into the current most recent lollypop repo so the old tree 
> could be removed earlier.

Maybe I was unclear above, let me try be more explicit:

My personal opinion: I see no need for you to incorporate my hostoric 
lollipop work into yours.

With my Purism-policy-nitpicker hat on: We have no policy regarding 
preservation of historic works, and if we were to establish such policy 
I would recommend that it would include something like "works containing 
no feature changes (e.g. only fuzzing and boilerplate changes) need not 
be preserved" which fit the case of my work packaging lollipop.

Now is probably the wrong time and place to discuss creation or changing 
policy - i.e. let's not discuss policy any furthere here unless to 
correct me if Purism *already* has an established policy on the matter.


> > I pointed to that historic git repo because a) it was unclear to me 
> > what Carsten wanted to say (he also referenced missing posts by 
> > Guido still unavailable to me¹), and b) I mistakenly focused on 
> > finding _best_ practice.
> 
> O.k. I might have not made it fully clear what my objection was.
> 
> I'd like to avoid to do work that is in my eyes more error prone than 
> the workflow I use for several years now if I do Debian packaging and 
> I've also have seen within a lot of other packages by developers which 
> I not know directly or have spoken too except by some email exchange 
> maybe.

I don't understand what you refer to as "more error prone" - but no need 
to explain what you mean unless you seek _best_ practice, see below...

Debian packaging works rarely involve multiple overlapping timelines.

Debian-derivative works more often involve multiple parallel timelines, 
due to the nature of Debian and the derivative distribution often being 
developed in parallel.

But caring about *how* to flatten parallel timelines only matters for 
_best_ practice: If you don't care about ambiguities on how parallel 
timelines get flattened by the tools you use, then just use whatever 
Debian packaging practices you are familiar with and hope for the 
best...


In short: Please ignore all of my posts in this thread if your interest 
is to use _easiest_ or _simplest_ or _quickest_ practice.  Only if your 
interest is in _best_ practice is my posts here any relevant.


> p.s. As I'm not able to do this without some help from users who are 
> able to do this (nor want to do this without an acknowledge from 
> others) we need to come to an agreement how we all can be happy.

For the record: I am frustrated that I feel alone about my views about 
how to _best_ handle multiple parallel timelines in packaging works.  
However, your working on PureOS packages makes me happy *regardless* of 
your packaging style: You are not making things _worse_.


 - 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/20211016/5fd8c942/attachment.sig>