Hi, On 2026-07-09 at 12:07+02:00, Hugo Buddelmeijer wrote: > On 9/7/26 10:25, Nguyễn Gia Phong wrote: > > 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?
I'm still using NixOS to host my services because we're still missing my prefered packages for mail and Matrix servers, but as a contributor, I really dislikes nixpkgs' approach to Go et al that hides the dependency graph. I also don't like waiting for CI to finish for updates to land on the unstable branch (the reliance on Hydra makes the development branch rather likely to contain broken packages). Nix DSL is also difficult for me to get used to, and I much prefer Guix channels over Flakes to package things for $dayjob. On 2026-07-09 at 12:07+02:00, Hugo Buddelmeijer wrote: > 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. Indeed, it's also common in nixpkgs to file a superseding PR to Ryan's bot's, and I think it's valuable to be pinged for updates over having to actively check if one is available. In my uneducated guess, it's easier to bump stuff when most packages' release date are within a short time period. On 2026-07-09 at 12:07+02:00, Hugo Buddelmeijer wrote: > 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. While the bots don't need to be able to do the work by itself, but as Anderson mentioned, most of the updates are hassle-free. Oleg also said in another subthread that we've accumulated much packaging debt. I wonder if you have any comment on my proposal on that thread (splitting..., cc'ed) to perform updates horizontally instead of vertically in topic branches. Or maybe it's just me prefering (metaphorical) marathons over back-to-back sprints. On 2026-07-09 at 12:07+02:00, Hugo Buddelmeijer wrote: > E.g. looking at some of your recent > Python commits [23180b4f6810^..1720ba0bf241] > > But it is exactly [3 non-trivial commits] that probably took most of > your time. So while a refresh-bot is essential, it can only do so much. I looked at the commit time and they each took under 10 minutes (except for the first two that were committed back to back, seemingly). This is about the time it takes for me to cherry-pick someone else's user-approved (small) PR, build and proof-read it for the last time. There are more difficult fixes, and while I'm happy to be _the_ benchmark, in these examples it'd be more effective to have a convenient way to browse blocking packages. If only there are no longer scrapers DDoS'ing the data services all the time! On the other hand, anything over 100 lines could easily cost me an hour to review in detail. Then I'm amazed at how Zig people just merge thousand-line PRs regularly, so I think lots of it is based on trust. Perhaps, see the following article: https://productpicnic.beehiiv.com/p/trust-is-not-built-on-craft-alone Per https://guix.gnu.org/en/blog/2026/one-year-with-codeberg we have about 30 committers merging 500 PRs a month. This is one merge per capita every two days, and on average there are about 2500 commits per months, and most PRs have fewer than 5 commits. Therefore, most of the updates must have gone directly to (sometimes master and) topic branches, which IMHO have a much higher barrier to colaborate on (lack of substitutes, unstable history, short open windows and much fewer reviewers). Best wishes, Phong
signature.asc
Description: PGP signature
