On Sat, Jul 25, 2026 at 02:11:29AM +0900, Simon Richter wrote: > On 7/23/26 20:12, Marc Haber wrote: > > > I still have to manually grep trough the sources of a package I maintain > > to manually create debian/copyright files instead of uploading the > > source package to an LLM asking for a debian/copyright file (and of > > course sampling whether the output makes sense)? > > Yes, because otherwise you are offloading this work to the DFSG team.
I think the review burden is a genuine challenge, but that's orthogonal to the matter of whether it was created by a human or an LLM. It's the quality of what is contributed that's the problem, not the nature of how it was generated. > The problem with AI workflows is that they move the effort from the > "writing" to the "reviewing" stage. Doing a proper review is more than > "sampling" the output, so the "efficiency" gain of such an approach happens > on the backs of other volunteers. In the specific example of reviewing debian/copyright, the DFSG team will need to review it carefully regardless of whether it is human written or LLM written. The amount of work they need to review is the same. > This is one of the main issues open source projects have with AI-generated > submissions: it takes more work to review these than it took to generate > them, in some cases even more work than writing the code by hand would have > taken. Only in so far as working with the submitter in the case of slop. If the submission was of good quality, then surely this is fine? I think a more direct solution in dealing with slop is for the community to be less tolerant of slop, however it originated. The further a submission departs from what is reasonable, the more reviewers should feel able to reject with less explanation. A rejection notice of "slop, not worth the effort to explain" should be considered OK now in response to the LLM revolution, whereas this might not have been the case before. There is no need for this to be attached to a requirement for us to determine whether the slop came from a human or an LLM. [...] > That is where the "loss of trust" comes from. I am happy to provide > extensive feedback if it helps someone learn, because that is how we build a > resilient free software ecosystem, but if that feedback is just going to be > pasted into a prompt, it is a waste of my time, but it registers as an > "efficiency" gain for the AI prompter, because my work is cheaper than even > AI tokens. I am concerned about this too. Specifically, what I'm saying is that we should adjust our culture to one where the amount of time a contributor can expect a reviewer to spend on their submission is limited to be proportional to the apparent effort that they themselves spent. If that's not enough for an effective review, then they should expect their contribution to be rejected. As a project we should not demand any more from the reviewer. I also think that reputation is more important now than ever. It is worth spending more time with somebody of high reputation. Somebody who submits slop should expect their reputation to be damaged, and if they have status (eg. they are a DD or a DM) then they should be sanctioned appropriately. This does mean that somebody with no reputation (yet) may feel slighted, and I understand concern that this may harm our ability to attract new contributors. But I don't think that's really anything new. Somebody unknown to a project who submits something huge and sloppy instead of starting small would have found it difficult to get their contribution landed prior to LLMs anyway. > > It could kill Debian. > > People getting frustrated with reviewing slop has a much higher chance of > killing Debian. I think the solution to this is to adjust our culture to set a low bar for rejection of slop and not require much of an explanation. The project should be prepared to accept this in sympathy to Brandolini's law. My point is that the issues you raise are valid but really apply to all slop, so on the matter of these specific arguments we should tackle the slop directly rather than worry about how the slop was generated. I think we should do this whether or not we ban LLMs, because even if we ban them, we're still going to get slop from contributors who deny their use. [...] Robie
signature.asc
Description: PGP signature
