Hi, On 11/10/26 3:16 AM, Richard Laager wrote:
If Debian had a team of CompSci student volunteers do first-round NEW queue review, and they had the same accuracy level and sent the same emails, would that be a problem? I suspect not, even though their output would also be "mostly-correct".
Indeed it would not be a problem, and there would likely even be volunteers to train them.
The difference is in the expectations we can set for students joining the project vs an LLM that is deployed as a tool: we expect that the humans can research unclear points in a self-directed way, and learn from the experience, and eventually reach a point where they can be given the rights and responsibilities of a full project member.
We cannot place the same expectations on LLMs, and if we tried, the pro-LLM camp would object that these were unfulfillable and formulated in bad faith to undermine progress.
So I don't believe there is any disagreement inside the project on output quality ("mostly-correct") or capabilities ("limited") of LLMs.
What we do disagree on is 1. what these properties mean for us 2. whether the dependence on non-free technology is a critical factor3. whether the DFSG team inserting an LLM into the review process means inserting them into maintainer workflows.
For the first point, the DFSG team can decide that for themselves in the short term. I think it is a bad idea because it makes the work more tedious, but they may feel different for now. I also think it is a bad idea long-term because it eliminates one of the "entry" positions to the team, so it will be more difficult to find new volunteers. This is a problem that free software shares with commercial software development.
I pretty much expect the DFSG team to become fed up with LLMs during the next year anyway, before the long-term damage arrives, so I don't see that aspect as an urgent priority.
I'm a bit more concerned about introducing non-free technology into our processes. Basically, if I wrote an important tool on top of WinAPI and deployed it by getting a Windows Server VM sponsored, then even if I argued that only the output mattered, and after all, our logo was made in Adobe Illustrator, I would get still quite a few odd looks inside this project. That is more generic than just NEW processing though, so it is kind of outside the scope of this thread.
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.
What if the emails were simply the output of lintian and other deterministic copyright analysis tools, would that be a problem?
No, because these tools are free software.The nondeterminism adds another layer: the criteria are unclear and shifting. I can easily check my packages with lintian before upload, and in fact I am expected to do so, and I can expect that lintian running on Debian infrastructure will either generate the same output, or there is a good reason for the discrepancy.
If the team had done that without discussion first, I would have been incredibly shocked if it received the same negative response.
The regular wnpp summary mails and the testing removal mails did receive quite a negative response when they were introduced. I think most other instances of tools mass-emailing maintainers were rolled back.
We *do* get a lintian report as part of the REJECT mail if this is what led to the rejection.
If those are not a problem, then the issue isn't the output or people getting emails they didn't ask for, it's simply that it was generated by an LLM. We voted on this and the decision was made; LLMs are acceptable.
That is only the beginning of the discussion, though, not the end, because right now there are no guidelines on what constitutes "responsible" use of LLMs. Discussions such as this one serve to find that out.
As of now, expectations for maintainers are unclear: 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.If I generate one, and roughly check whether it looks plausible, then upload, then I'm offloading my work onto the DFSG team. That would be a dick move, but 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 I generate one, roughly check whether it's plausible, then upload, and then the DFSG team runs another LLM to check, then we have built a system where an LLM verifies LLM output. Having them communicate through uploads seems silly.
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, and likewise is writing a file by hand, then comparing against the LLM output. Again, no "efficiency" gain here.
Likewise, if the DFSG team rolls out a review LLM, the expectation can be one of multiple things:
1. The DFSG team are the only people ever to read that output. If they feel like doing that, I don't have to understand it, but more power to them I guess, and I can ignore that completely.
2. I am supposed to read the report, and act upon it in order to not waste the time of the DFSG team. 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), and at the same time it communicates to me that they do not expect me to write my copyright files diligently.
If that is the case, and I use an LLM to perform the requested changes, then again I have created a loop of two LLMs, one that produces output and one that reviews it, and the interface between them is the upload queue.
Obviously the LLM loop is the wrong approach, so as a maintainer I'm no longer supposed to use an LLM when the DFSG team is already doing so. Am I then expected to prepare a report listing any false positives in the LLM report in order for the upload to proceed, or can I ignore that because I can expect the DFSG team to verify these reports before contacting me about them? Do I need to revise my rebuttal of the LLM report if the LLM is rerun, and generates a different result?
The current reading of the GR suggests that this is indeed the duty of the DFSG team, which is why I asserted earlier that I expect them to get fed up with LLM use soon anyway.
3. Something in between, where I'm supposed to read and act on the report unless I'm complaining about this, at which point it becomes optional to defuse my complaint, then returns to being expected, or where it remains optional for now to defuse my complaint, but is turned into an expectation later.
Right now, the perceived improvements stem from these questions being unanswered, so we can assume the optimum outcome for every partial aspect until we have measurements available, but these optimum outcomes cannot be all realized at the same time because they are interdependent.
That's why there isn't even an ethical dilemma for me: there is nothing of value that I have to give up if I reject LLMs. The dilemma is created by an automation process tying "contributing to Debian" to "using an LLM."
The result is that contributing to Debian now feels morally wrong. I still sometimes sneak an upload in if I can guarantee that it will not go to NEW, but I'm often catching myself thinking "I'd rather be doing literally anything else."
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, 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.
Simon
OpenPGP_signature.asc
Description: OpenPGP digital signature
