Hi,
On 9/7/26 10:25, Nguyễn Gia Phong wrote:
Hi,
On 2026-07-08 at 19:38+02:00, Hugo Buddelmeijer wrote:
Adding a new package to [nixpkgs] requires you to either
become a maintainer yourself, or find someone
who is willing to adopt the package.
For context, when I was an active contributor to nixpkgs (2020-2024),
the maintainer field merely meant "subscribers to its issues and PRs".
A large part of updates are proposed by Ryan's bot, approved
by a "maintainer", merged by someone else with commit right,
and finally land on the user channel after CI finishes building.
Why did you make the switch to Guix?
Yes we should definitely build such a bot.
Independently from that I do think that having such a dedicated
maintainer in the loop is a big part of their success, even if the
maintainers usually don't do much.
I'm a maintainer of some conda packages and I do exactly what you
describe; approve automated P.R.s. Every once in a while, a problem
arises, that I can trivially fix, because I know those packages very
well, while it would take someone else easily 10 times as much effort.
So having dedicated maintainers reduces the load by a factor of 10.
We don't have to organize ourselves like Nix, that is fine. But Ludo'
explicitly said to take inspiration from them, so I replied with what I
think is a big reason for their success.
We might even have a potential for a bigger success with our more
collaborative approach. For example because sharing responsibility
requires sharing knowledge. (And while we are doing that very well, we
should do much better.)
(E.g. I have no clue about why any of the complications in the onnx
package are there, so I need to redo all the previous work before I even
know how to proceed.)
In my analysis a couple weeks ago, 30k/32k packages in our channel
has no more than 300 dependants so their update could be triggered
by a bot without overwhelming CI.
I rated Nix's dedicated maintainers as a more important factor than
their bot, because I don't see how a 'normal' bot can do the work
required for many of these 30k updates.
E.g. looking at some of your recent Python commits [1]:
Can most likely be automated easily:
https://codeberg.org/guix/guix/commit/1720ba0bf241c4489d04db0703ed5ff899b881c0
Probably possible to automate with effort:
https://codeberg.org/guix/guix/commit/3515ff78fdbc931374a9bf4aa16993f280b8ce98
https://codeberg.org/guix/guix/commit/adc94a2bdb3b664d6c943d3b19d45891a3419406
Can probably only be automated through an agent:
https://codeberg.org/guix/guix/commit/b45ee5ab273f7abfa260103f22334fa6a9a22bbf
https://codeberg.org/guix/guix/commit/a04a0846292831a860166d3ea4cd8e9d56172841
https://codeberg.org/guix/guix/commit/23180b4f68104da421a79716592cbdbad1a2cf8e
But it is exactly those last three commits that probably took most of
your time. So while a refresh-bot is essential, it can only do so much.
We can commit to not have agents propose patches on moral/ethical/legal
grounds, that is an acceptable viewpoint, albeit a shortsighted one in
my opinion.
But then we need to be honest w.r.t. how much extra work we want people
to take on (time that cannot be spent elsewhere); we should not hand
wave that away.
(And yes, in the past there was no other way to do the work; so the work
was not 'extra' then, but now it has become 'extra'.)
Hugo
[1] Those commits are the first six commits from
git log
b7934f4192a1cc225509dd927c1bb1d211ad355b..dfb6f229e5f62de62723b8b8185678eade9107f9
--author="Nguyễn Gia Phong"
where that range is the end and start of the python-team merge.
