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