Re: Guix (and Guile's) promise, and how to (hopefully) get there

[indieterminacy <indieterminacy@libre.brussels>]

On 2024-10-26 18:40, Suhail Singh wrote:
> Christine Lemmer-Webber <cwebber@dustycloud.org> writes:
> 
> ...
> 
> Specifically, the bulk of patch submissions in Guix deal with packages.
> Barring some core packages, perhaps Guix would be better served by
> splitting other packages into a separate channel.  The organization and
> management of said channel could be optimized for tracking upstream as
> closely as possible.  OpenSUSE's Factory model with OpenQA comes to 
> mind
> [1].
> 
> #+begin_quote
>   The core of Factory is divided into two rings (0-Bootstrap,
>   1-MinimalX). Ring 0 contains packages that form the most basic,
>   minimalist system that can compile itself. On top of that Ring 1 adds
>   what's in the default installation of the two primary Desktops. All
>   other packages are not part of a ring.
> #+end_quote
> 

Having explored the ecosystem of certain tools (what is a dependency of 
other dependencies),
I have wondered about how this plays out in terms of governance 
(particularly priority or emphasis).

For instance, many tools eventually have a requirement for Perl - given 
that eventually a supporting tool may provide a need for its regex or 
build qualities.
Now, its quite likely that the version for Perl is not an inhibitor for 
other tooling to increment as versions.
However, I do not know whether this (or similar tools) are articulated 
in a centralised and documented environment.
(I do read references conversationally from this ML from time-to-time, 
especially when discussing packaging for specific languages - but such 
fleeting opinions are not necessarily the same as a dedicated resource 
with a uri to point to).

Practically speaking, is it worth each team concretely highlighting 10 
core tools to prioritise and maximise documentation and policy for?
As well as 3 tools which their circle creates, that are important for 
other tools in other team circles?

Such a procedure may allow more of a tracking over time of changes of 
priority, as well as a better attempt at gauging how such priorities are 
being treated.

> Orthogonally, the project would IMO also benefit by having automated
> testing to ensure that the combination of packages work well together.
> 
> As things stand today, the incentives for those without commit access
> are such that it makes better sense for them to focus on their own
> channels.  This is a shame.


On the topic of cloud/service type activities, Im still intrigued by the 
allure of Guix wrt forge services.

While I understand Arun Isaac may have other/greater priorities than to 
focus entirely on his guix-forge project,
I have wondered about having Guix/Guile being considered a column in the 
code forge domain:
https://git.systemreboot.net/guix-forge/about/

After all, if something  can be configured once in Guix it can be spun 
up, and reproduced in a sustainable and functional way -- this should be 
a point of distinction for this community.
If enough hackers control the form of how code is stored and transmitted 
then many points of concern could melt away.
Positions such regarding centralisation or decentralisation of package 
definitions or regarding (Neo) AI would reconfigure if Guix had more 
sway over forges.


JM