On Wed, Jun 17, 2026 at 3:59 PM Ludovic Courtès <[email protected]> wrote: > > Hi Greg, > > Greg Hogan <[email protected]> skribis: > > > I was reading the document sliced with the codeberg comments. I agree > > with the goals and only take issue with commitment #1, the project > > prohibition on the use of GenAI. These are powerful technologies, but > > I trust our community to use them responsibly. > > Several people suggested distinguishing between using an LLM for > exploration and using an LLM for authoring.
How are we distinguishing exploration from authoring? Are we including running Guix commands under exploration? So that when updating a library resulting in a dependent package failure (x1000) the LLM could run `guix refresh` on the failed package and rebuild? Or if the agent explores the failed log file, searches on the error message, and finds the patch in a project PR/commit/email, the agent could copy (not author) the patch into the repo and use a guix tool to modify the package patch list? > For this reason, the first item lists specific uses, and exploration is > not among those: > > 1. The project (defined as maintainers, team members, and anyone with > write access to a Guix repository, including Weblate, or to Guix > resources such as the build farm) **will not use nor encourage use > of genAI** to author code or packages, to review code, to produce > artwork, > translations, or any other artifacts. > > Does this address your concern? > > If not, what change would make it acceptable to you? And what would be > ideal to you? (The two answers may differ.) We also need to document what the project and contributors are permitted to do with GenAI, including exploration. > > The power of GenAI to discover vulnerabilities is an especially strong > > reason to keep packages up-to-date. Why the concern over automating > > some of the most mundane, neglected tasks when there is so much work > > to be done? > > I’m all for automating package updates! I wrote ‘guix refresh’ early on > in the life of the project and it has since benefited from all the work > that has gone into importers. I experimented with auto-updates from > CI¹. I suggested several times that we should set up something like > Nixpkgs’ bot², which has allowed it to be both the largest *and* the > most up-to-date distro³ for several years now—without any LLM involved. > > Others have done great work such as the automated updates of Guix-CRAN⁴ > (~30k packages), the periodic updates of the astronomy packages by > Sharlatan, and so on. > > The pledge explicitly acknowledges this need and the work that must to > be done to address it (item #5). > > In short, we violently agree on the need for automation for package updates. > My take is that we already have great tooling for this and we need to go > the last kilometer to use it to its full potential. That’s where the > low-hanging fruits are, as the Nixpkgs experience has shown. > > WDYT? I am not so certain that the community wants to automate package updates. Like donating cans to a food bank, we know that you should never buy food to donate to a food bank, just give the money and they can buy what is needed when needed. And of course the cans of food must be sorted and distributed by volunteers rather than purchased on pallets direct from the distributor. But food banks must pretend to want the canned food drives. It is certainly a risk to automate the trivial but low-value package updates to focus (and by focusing) on these automation features. And if automation makes the project less accessible, LLMs can make contributing more inclusive and equitable. What has impeded us from building out these wonderful new features? Does not the number of contributors and committers continue to grow?
