Matthias Geiger dijo [Tue, Aug 11, 2026 at 07:57:59PM +0200]:
On Tue, 11 Aug 2026 17:18, Marc Haber <[email protected]> wrote:
On Tue, Aug 11, 2026 at 04:10:00PM +0200, Gard Spreemann wrote:
In order to safeguard the project's mutual understanding, trust and
respect, we disallow the output of generative AI as direct contributions
to Debian.
This wording leaves HUGE possibilities of interpretation and will
therefore cause a lot of flamewars.
I agree in the feeling this new proposal carries a lot of ambiguity and
makes me feel uneasy even to determine its meaning.
Claude is not a DD, it therefore cannot contribute directly to
Debian. When I say "Claude, create a Debian package doing foo and
set myself as a Maintainer", is that a direct contribution?
Yes.
Does the direct contribtion become indirect when I fix the Lintian
errors that Claude causes myself?
Yes, but since foo was created with an LLM, this is irrelevant.
But, if a Debian contribution is created by an LLM, then vey carefully and
thoroughly checked by a human... would that be acceptable?
I understand the low-quality issue that stems from output being
probabilistically generated by a machine that cannot be expected to
understand *anything*, but if a machine-generated tool is carefully checked
by a capable human, do you still believe it is unacceptable?
Simple example:
Lintian complaining that a package has no watch file. An LLM might try
to "help" by writing a d/watch file. However, without context, this
can be totally wrong. If the package has no VCS upstream or isn't
developed anymore, a watch file makes no sense. A seasoned contributor
will know that and ignore/override said warning; an LLM can't.
Another example:
An LLM "offering" to override tags which point to underlying package
issues, such as shared libraries not correctly split into their
respective packages. Arguably, a experienced contributor will spot
that,
but a new one might believe the machine.
I remember many years ago, maybe around 2010, I wanted to package
OwnCloud. There was another DD who was interested in the same thing. We
were both “seasoned”, for some value of it (in my case, if it was 2010, I
had been a DD for ~7 years already). We prepared a package, and _thought_
we had done a decent job.
But we didn't look hard enough: There was a whole directory (lets call it
“vendor”; I don't know if the term was well in use back then). I didn't
expect a PHP project to carry *so many* dependencies undeclared to the
world inside of it! Back then, I thought that finding out the other PHP
packages it depended on (i.e. database access, caching and the like) would
be enough.
The ftp-masters were not amused, and if I'm not mistaken, we got a swift
REJECT. And, of course, soon realized it was essentially impossible to
package programs such as OwnCloud because of the way their developers
decided to interface with the universe.
Where I'm trying to get — An LLM will try to fill in any gaps you have in
your specification, and will often do it *wrongly*. Even if specified, if
it overflows its attention span, it will flow undetected. But that's why we
will keep insisting on human oversight _and accountability_. The packages I
upload and the patches I propose are _mine and mine only_, and I as the
human I portray myself to be carry the responsibility of doing the right
thing. I also make mistakes (many!), but at least I have been approved not
to make too many, or too dangerous mistakes.
— Gunnar.
