Hi all,
On 9/7/26 21:43, Ludovic Courtès wrote:
Hugo Buddelmeijer <[email protected]> skribis:
From discussions I’ve had with long-time Nixpkgs contributors both in
real life and on Mastodon, they seem to agree that r-ryantm bot is a key
factor (which I didn’t expect).
Why it be unexpected that they consider he bot a key factor to their
success? What did you expect?
It makes sense to me, but only because they already have a baseline.
E.g. they would not credit using git as a contribution to their success,
even though I'm sure git is a bigger factor than r-ryantm.
Their baseline is, I think, that everyone maintains a specific set of
packages that they know well. When you know a package through and
through, you can solve any problem quickly. When someone tells you that
a new version of library X breaks your package, you immediately suspect
why and fixed it in your head before even looking.
With such a baseline, most of your maintenance time would be spent doing
mundane routine things that you have done 100 times before. Then an
update-bot is super effective. (And an AI-agent wouldn't really add much.)
With Guix, despite its potentially superior collective maintenance plan,
most of a maintainers time is updating/fixing dependencies or dependents
that they are unfamiliar with. At least for me, I had never heard of
onnx until we broke it with a NumPy update.
With such a baseline, an update-bot would not do much, because updating
is not where the time is spent. Especially since `guix refresh` exists.
(An AI-agent would help enormously though, even if it would only
explain without writing any code.)
I did came to see the collective maintenance approach as ultimately
better. Primarily because I learned so much from all these random
packages. But we need to make our process smoother if it is to succeed.
And I don't mean technically, but socially, with respect to sharing
knowledge. (We are great at sharing knowledge already, we should
capitalize on that.)
The GCD allows "exploratory analysis" using genAI, which is good, but
there is a big problem with that that the GCD does not mention, because
such LLM-use has he potential to replace human-human interaction. If we
need an LLM to understand why a package is written the way it is, then
we failed somewhere, and we should improve our communication.
That is, I'd rather have an LLM write the package, and have humans talk
to each other, than have humans write the package, and have an LLM talk
to humans. I think the GCD has it backwards ;-).
Hugo
