Ricardo Wurmus <[email protected]> writes:
As a project we should certainly not host a channel for things
that we
don't take responsibility for. Whoever wants to have a vibecode
channel doesn't need the project to make it for them, but it
would
benefit the project as a whole if we ironed out the kinks in
dealing
with more than a handful of channels.
Wholeheartedly agree with this. Right now using multiple channels
can
quickly get painful as APIs shift within each of them, but I think
there
are enough valid use cases for alternative channels that it
behooves us
to make that process smoother.
I maintain an internal channel at my employer for some development
tooling in an attempt to encourage Guix usage there, but keeping
it up
to date with Guix upstream (and making sure users are able to
`guix
pull` without fear of breakage while they have the channel
configured)
has been a challenge at times. And I know maintainers of other
channels
(e.g. guix-science) have had similar challenges.
I think the best outcome here might be for LLM users wishing to
use Guix
to start their own channel and keep any LLM use confined to that
channel, and for Guix upstream to smooth out the process of
managing
external channels. We'll all benefit from the latter.
