On 2024-10-26 18:40, Suhail Singh wrote:
Christine Lemmer-Webber <cweb...@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
