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.
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.)
>> If you would prefer no regulation on LLM usage within the project,
>> please consider this comment:
>>
>>
>> https://codeberg.org/guix/guix-consensus-documents/pulls/13#issuecomment-16470989
>
> I am confused when I read "Are AI contributors going to use and thus
> maintain and extend tools such as guix import, guix refresh, and guix
> style that would now compete with agentic genAI". Agents use rather
> than compete with tools.
Yes, to some extent. In practice, it is also tempting to use agents for
mechanical changes that other tools perform well such as refactoring (of
the kind ‘guix style’ and IDEs like Eclipse implement).
> I don't believe that anyone is looking to upgrade a package using an
> LLM (other than as a test case). I see that GenAI adopters are looking
> at challenges like updating core packages and libraries with 10,000
> dependents without playing version update whac-a-mole. And in order to
> make efficient use of project resources we must necessarily group
> packages updates, which confounds debugging.
Updating packages with thousands of dependents raises several issues
(speaking from my long experience with Guix and with Nixpkgs before
that):
1. Knowing whether dependents break. This is what ‘guix build -P1’ and
CI help with.
2. Fixing said dependents. So far that has always involved a number
of techniques, including learning from other distros.
3. Scheduling rebuilds. This involves a mixture of social and
infrastructure issues (info "(guix) Managing Patches and
Branches").
One could use LLMs for #2; according to the pledge in its current form,
this is fine as long as the change itself is authored by the person or
is not “legally significant”.
The main bottleneck in Guix is often #3.
> 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?
Ludo’.
¹ https://lists.gnu.org/archive/html/guix-devel/2024-12/msg00011.html
² https://nix-community.github.io/nixpkgs-update/r-ryantm/#r-ryantm
³ https://repology.org/
⁴ https://codeberg.org/guix-science/guix-cran
