[PureOS] Updating localechooser in landing/byzantium

[Jeremiah C. Foster]

Hello again!

On 10/7/21 3:51 AM, Guido Günther wrote:

> Hi Jeremiah,
> On Wed, Oct 06, 2021 at 04:22:55PM -0400, Jeremiah C. Foster wrote:
>> Hello,
>>
>> On 10/6/21 12:29 PM, Carsten Schoenert wrote:
>>> Guido,
>>>
>>> Am 06.10.21 um 16:38 schrieb Guido Günther:
>> <snip>
>>>> Again I have no strong opinion here but rather try to understand why one
>>>> would use a different workflow as with other packages (which
>>>> e.g. results in the discussion being split between mailing list and
>>>> giltab).
>>> Well, the thing is still, there is no branch I can start a MR against
>>> (at least I think). There is not even yet a tag 2.93 on soure.p.s.,
>>> there is currently only the old master branch which isn't connected
>>> anyhow to the "mother" tree on Salsa.
>> This is an issue with all packages on source.puri.sm - both pureos/core and
>> pureos/packages are not connected to Salsa or to Laniakea.
> By far not all. /Librem5/debs space uses full sources mirrored from
> salsa so do many projects I've encountered in the PureOS /core and
> /packages spaces. Just one exmple from each:
>
> https://source.puri.sm/pureos/core/dpkg/-/commits/pureos/master
> https://source.puri.sm/pureos/packages/gnome-control-center
>
> There's many more and new ones also use this pattern to my
> knowledge.

That is fantastic! In my experience that was not the case but looking at 
the package lists of core and packages now I can see that there are many 
updated as you say. Other's say "fork from Debian" and some are years 
old or month old but they may have newer branches, etc.

If we could use those two package repos going forward, we might be able 
to determine a minimum set of PureOS forked or modified packages that we 
can evaluate for support over the longer term if we chose to support 
Amber longer than it's current security service going forward. We have 
more "PureOS only" stuff in Byzantium I assume so the sooner we can 
define that minimum set of things we need to support (and for how long) 
the better we can allocate resources that work.

>> These repo groupings (core and packages) likely no longer serve the same
>> purpose as originally - namely to be "complete and corresponding" source
>> code for all the packages in PureOS. We likely ought to have a plan or
>> create one for how we can have a one-to-one correspondence between source
>> code in a git repo and the binaries in the archives to make support easier.
>>
>>> If it would exist at all this mail traffic wouldn't needed and I've
>>> started directly any discussion within a MR.
>>>
>>> If the outcome is there is no problem to create a starting branch
>>> pureos/latest by preparing the tree on source.p.s then I'm of course
>>> fine with this.
>>> I'm unsure if I would can do that, given to the permissions for
>>> Developers I should.
>>>
>>>> My take for using merge requests for about everything is that it keeps
>>>> the discussion close to the code (and searchable).
>> This makes sense but this list can be a very valuable resource for those new
>> to PureOS, for making policy, and for other co-ordination. So I for one
>> welcome Carsten's mail to the list.
> We can forward all of gitlab traffic to from the PureOS space to this
> (or another) list or better explain how to subscribe to all changes there.

So you'd rather de-commission or deprecate this list? Isn't following 
even just the PureOS space via a RSS type feed a _lot_ of mail? I'll 
import it into my inbox to see how much myself. I can see a benefit of 
having fewer communication streams.

Regards,

Jeremiah