Jonathan Carter <[email protected]> writes:
> I don't agree with this sentiment. I don't want slop in Debian, but as
> more and more upstreams increasingly use various AI tools, I believe
> it's becoming increasingly urgent for Debian as a project to have some
> guidelines on this. Many of us feel the same way. As Ansgar mentioned in
> another follow-up, rsyslog should probably be out already. So policy
> would really help in *preventing* slop and code with questionable
> copyright.
I'm not going to touch on the copyright part. I have nothing meaningful to
add to the legal discussion.
Trying to exclude AI-assisted code from the archive on quality grounds
doesn't make sense to me. If you, like most people who are unimpressed by
LLM-based coding tools, don't believe that LLMs are some sort of quantum
leap over humans and tend instead to produce mediocre and sloppy
boilerplate code, then somewhat by definition humans are just as capable
of writing much *worse* code than LLMs as they are of writing much
*better* code than LLMs. Writing meaningless slop requires no creativity;
writing really bad code requires human ingenuity.
procmail is still in the archive, for heaven's sake. [1]
I too am concerned about the potential degredation in quality of free
software given the *volume* of bad code that people can generate using LLM
agents, but the objectively worst software in the archive is the product
of human ingenuity and I am dubious that's going to change.
Making rules that require us to make all sorts of guesswork judgments and
that are effectively unenforcable in practice (no one is required to
inform us if they use LLMs) strikes me as a recipe for endless future
arguments, which doesn't seem very likely to improve the average quality
of Debian packages. Or the experience of being a Debian Developer.
If we think software is bad, we should remove the software because it's
bad. I am quite dubious that investigations into the software development
tools used by upstream are going to give us much additional information on
top of the sorts of metrics we already have readily available (bug rates,
CVEs, user complaints, unexplained behavior changes between releases,
regressions, lack of necessary feature development, etc.).
[1] For those who don't know the reference, this is not intended as a slam
against procmail's functionality or against the people who have worked
to keep it viable all these years, but is a reference to procmail's
notoriously, uh, unique coding style and carefully (?) hand-coded
security-critical string manipulation in C.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
