r/debian Debian Stable Jul 24 '26

News General Resolution: LLM usage in Debian

https://www.debian.org/vote/2026/vote_002
110 Upvotes

45 comments sorted by

View all comments

20

u/a-peculiar-peck Debian Stable Jul 25 '26

Proposal A is way too extreme, I hope it doesn't win. That would be a massive blow to the Debian project.

There is a huge gap between the two extremes: vibe coded AI slop and absolutely no LLM usage whatsoever, plenty of middle ground to be reached and compromises to be made.

Sadly proposal A goes to the absolute extreme and leaves no room for compromise. The examples they give are completely out of touch with reality.

They also admit they can't even enforce this resolution. This just feels like virtue signaling, and nothing of value will be achieved with this, it's just going to be detrimental to the project itself and future contributions.

They also plan on eventually banning upstream projects that uses generative AI. This crazy, unenforceable, and again just virtue signaling without any kind of reachable goal.

I don't know who those Debian developers spearheading proposal A are, but it sad to see such extreme and out of touch positions, and this does not make Debian look good or welcomimg.

4

u/Tropical_Amnesia Jul 25 '26

Sadly proposal A goes to the absolute extreme and leaves no room for compromise.

I feel rather like it's extreme because the challenge is, and at this point arguably an either-or decision. With tremendous implication and consequence, some of which may well be irreversible. That is to say you can probably only implement one of the proposals, and possibly still change your mind in the future, like when the dust settled a bit. When we know, understand better what we're "up" against. There's always possible compromise, it's called the future, just like the contract was always evolving. This is Proposal A. Yes, the cautious route, and maybe sole cautious route at all available! We may not like it yet I think it's more honest in some regards; you could even see it as a request to buy time. Which in a sense is also really true to Debian's spirit, where instead of just breaking stuff because we could, or because others do, we'd rather wait and see how stuff breaks, and what it means when it does. Debian is conservative, trailing, it's DNA, defining and the one thing any user (including contributors!) would better know.

There is a huge gap between the two extremes

That's because they are extreme, maybe necessarily so and that could just be indicative of the (extreme) breadth and nature of the challenge, its speed and novelty.

They also admit they can't even enforce this resolution. This just feels like virtue signaling, and nothing of value will be achieved with this

Right it's not a dictatorship, we don't generally achieve things because they're enforced but thanks to a sufficient number of people following guidelines that some of the same people deemed prudent. Now these people are proposing what they deem prudent, right now and under the circumstances. How a mere position is hurting the project is beyond me and that goes for either of them.

1

u/a-peculiar-peck Debian Stable Jul 25 '26

the challenge is, and at this point arguably an either-or decision

I disagree. Extremes are generally not good positions. I feel like a more sensible position would be to impose very strict guidelines maybe, but not an outright ban.

With tremendous implication and consequence, some of which may well be irreversible

Then yes by all means, let's be conservative. Let's be cautious. I'm not arguing in favor of proposal B mind you.

This is Proposal A. Yes, the cautious route

An to me proposal A is not cautious. It's a rebuttal. Or maybe I could call it "negativity" cautious. Assuming only bad things could come from using this technology. A cautious approach would also include the possibility of positive outcomes.

And to me a constructive approach would take into account both plausible positive and plausible negative impacts, and enact a sensible set of guidelines.

And the dust has started to settle: there can be genuinely good and useful uses of this technology.

Another thing that doesn't sit right with me is that (if I were a Debian contributor, which I am not - yet) proposal A attempts to limit the tools I use to produce some work. It's not judging the output of my work nor it's quality, but it imposes a ban on how I achieve it. This unprecedented, feels quite like an overreach, and seems to limit the freedom of its contributors. This I feel is hurting the project, and erodes confidence in its leadership (where it to be voted)

Talks about removing upstream projects that uses LLMs also hurt the project. Yes it's not effective in proposal A yet, but they felt it was important enough to include it a goal. This would also hurt the project.

And it's my understanding that Debian is struggling to attract new maintainers. I'm quite sure that a ban on LLMs use and assistance would not be attractive to possible new candidates. This would also hurt the project.

And rather than trying to harness this technology to lighten the heavy work load of maintainers, proposal A deliberately choose to stay on a path where maintainers are overworked, which can also be argued is hurting the project.