On 2026-11-13 10:52, Simon Richter wrote:
I'm a bit more concerned about introducing non-free technology into our
processes.
You're not wrong, but everyone understood this when voting.
I'm writing this email on a laptop that surely has non-free firmware. I
wish it didn't, but there are many things about the world I wish were
different. I have to make the best of the hand I've been dealt, and
sometimes that means compromises. (FWIW, I have not yet used any
generative AI for Debian or other FOSS coding. I have used it to review
and poke holes in some emails I have written by hand.)
The bit I'm unhappy about is that this adds a step that I object to, to
a workflow that I cannot avoid if I want to continue maintaining my
packages, so in essence we went from "LLM use is acceptable in Debian"
to "LLM use is mandatory" within a few weeks.
Are you simply saying that you're unhappy, or are you implying that the
DFSG team is doing something wrong (like violating the GR) here?
I don't agree with your framing that *someone else* running a tool on
things that you send them means we have made use of that tool mandatory
for *you*. If someone checks their email with Microsoft Outlook, that
isn't making Outlook use mandatory for me because I email them.
As of now, expectations for maintainers are unclear:
In what way? You go on to give examples of how you could or couldn't use
LLMs, but what is *unclear*? You can use the tools or not use the tools.
for example, I can
write a copyright file by hand, generate one using an LLM, or do both
and then compare them.
If I keep writing it by hand, then LLMs do not provide me any benefit.
Obviously I can't speak to what works for you individually. You also
used copyright files as an example. I assume you meant to make a general
point here, so I'll address the general point, which I read as: LLMs
reviewing hand-written work do not provide a benefit.
The world is currently experiencing a "patch tsunami", where tons of
security (and other) bugs are being found in software (both open and
closed source) with the help of LLM tooling. This clearly establishes
that LLMs can find real, significant, bugs in human written software.
Finding those bugs is clearly a benefit.
in my experience that is how "efficiency" is achieved
using an LLM: by creating something that is "good enough" to give to
someone else to polish in review. We've had a few PRs like that at work,
and it led to a no-AI policy rather quickly.
If someone is doing their job halfway and pushing problems on others,
that's not a tool problem.
If I generate a copyright file, then go through it line by line to
verify correctness, that is more work than writing it by hand in the
first place
As a general rule, I can read faster than I can write, so that workflow
might be useful to me. Or it might not, but I can make that choice for
myself. You are free to use a different workflow, including a no-LLM
workflow.
2. I am supposed to read the report, and act upon it in order to not
waste the time of the DFSG team.
You can optionally read and act upon it.
If you do, your package is likely to get through review faster because
1) you will be able to fix any real issues found before the DFSG team
has to review and repeat them back to you, and 2) you can rebut any
errors so the DFSG team sees that rebuttal at the same time as the
initial findings, avoiding a back-and-forth delay.
Also, since the feedback is automated, it should come back shortly after
you upload, which means you get it while the package is still fresh in
your mind. In contrast, feedback filtered through a DFSG team human
comes later, after you have context switched, which is less efficient.
This is somewhat "efficient" for the
DFSG team, as they have offloaded part of their work to me (which would
also be a dick move)
"Their work" is that they are people who have volunteered to review work
from you, me, and the rest of us, to help ensure that our project meets
our collective standards and avoids unnecessary legal risks.
it communicates to me that
they do not expect me to write my copyright files diligently.
Long before LLMs were a thing, we had people reviewing packages and
their copyright files in the NEW queue.
The FOSS world has long had code review.
The existence of review does not imply an expectation that people are
not diligent in their work.
The veganism comparison from the other branch of this thread is apt: if
you decide that the book club meets in the steak house
where you have to
preorder a steak for every seat you reserve,
[In an effort to steelman your argument... This piece feels like a
stretch to the analogy, and I don't think it changes your position if
it's omitted.]
then the vegans will skip
the meeting, and that is not them forcing their beliefs on others, but
the others forcing beliefs on them by using the club as a means to exert
social pressure.
Some people in the book club wanted to meet at _only_ vegan restaurants.
They introduced a vote on this. The whole book club voted. The initial
proposal turned out to be a minority position.
The winning option is that we neither endorse nor prohibit eating animal
products. Members of the book club are free to eat what they wish. We
explicitly decided we will not create special rules around food made
from animal products.
A subcommittee of the book club, consisting of no vegans, decided to
meet at a steak house (analogy stretching) and do their subcommittee job
(reviewing books for future meetings, let's say). As part of that job,
they sent photos of their steaks (analogy stretching further) to other
members of the book club, one at a time, that were interacting with them
(proposing books). This upset the vegans.
The subcommittee agreed to stop sending pictures of their steak to those
who identified as vegans. (This is the opt-out.) I said that while "not
sending pictures of your steak" would be a special rule around food made
from animal products (which again, our vote just said we were *not*
going to do), it would nonetheless be a good practice to generalize.
All the while, some vegans have been calling for disciplinary action for
those who decided to send pictures of their steak.
Of course, the analogy breaks down a bit, as analogies do. Pictures of
steaks have nothing to do with the assigned job of reviewing books. In
the real situation, LLM reviews of a wad of text based on many piles of
text are perfectly reasonable. (Someone here recently called it "exactly
the right tool for the right job" or similar.) And when you are using a
tool as part of your review, making that output available to the person
who provided the package being reviewed is clearly in the interest of
transparency and is likely useful to them (as discussed above). Maybe
the DFSG team should have predicted that sending LLM output to the
anti-LLM minority would offend them and should have built the opt-out
initially. But they didn't do anything in bad faith or with malice that
should justify disciplinary action.
--
Richard
