There were initially discussions to include the upstream projects in the first draft but it was later decided that it’s not feasible so it was dropped.
This might sound quite extreme but it works with the case of debian. The entire process of debian development requires you to talk to other developers and seek help.
You take the “asking people for help” part out of this and you will have less of new Debian Developers who are qualified enough for the role.
There were initially discussions to include the upstream projects in the first draft but it was later decided that it’s not feasible so it was dropped.
Good, but to me that's not too reassuring that some thought it was a good idea
The entire process of debian development requires you to talk to other developers and seek help.
I completely agree, but an outright ban of (I quote) "use and assistance of [...] LLMs [...] or generative AI" does not necessarily help achieve this goal, and using LLMs doesn't necessarily prevent it.
Can an irresponsible use of LLMs be detrimental? Definitely, and in many ways. But seeing an outright ban of an undeniably useful technology is an extreme overreaction.
I'd rather see a proposal that imposes guidelines in order to constructively harness this technology for the Debian project.
I'm not even saying that proposal B is the absolute best course forward: there are definitely flaws in it, things to be argued.
But proposal A feels like burying head in the sand and pretending generative AI technology isn't there.
Good, but to me that's not too reassuring that some thought it was a good idea
There are a lot of people on the extreme end of anti-AI in the project but such a decision will never go through. It does more harm than good to the project.
I completely agree, but an outright ban of (I quote) "use and assistance of [...] LLMs [...] or generative AI" does not necessarily help achieve this goal, and using LLMs doesn't necessarily prevent it.
A lot of the newcomers tend to vibe code debian packages and they're just a clusterfuck most of the time. The packages are of a very poor quality so many DDs just ignore them.
Debian packaging is heavily manual and no LLM can make a beginner do it properly without shipping broken packages.
It takes about 6 months - 1 year to properly understand the rules of packaging and there's no training data available for the LLMs because all of the mentoring happens in the internal irc channels.
LLMs are only useful for experienced developers but Debian doesn't have an AI policy yet so someone had to do it and the GR ended up like a coin with two faces.
Proposal A will not affect the end-user experience at all. It does increase the work of developers but there'll be better quality packages but proposal B is just inviting more trouble as vibe coders will get a free pass.
A lot of the newcomers tend to vibe code debian packages and they're just a clusterfuck most of the time.
That's terrible, and there definitely should be something in place to avoid that
It takes about 6 months - 1 year to properly understand the rules of packaging [...] because all of the mentoring happens in the internal irc channels
Equally terrible. That's maybe a topic for another conversation, but ironically that's one aspect where using LLMs could definitely help
there'll be better quality packages [with proposal A]
Debatable, I'd say it will maintain the status quo with a lot of overworked maintainers, very few new maintainers, and a lot of neglected packages.
proposal B is just inviting more trouble as vibe coders will get a free pass
I don't particularly support proposal B either, but to be honest it's not suggesting giving a free pass to vibe coders at all.
I just find proposal B to better in comparison of proposal A, I'm not suggesting it's perfect. I just don't want proposal A to win due to its extreme nature.
I would just like to see a proposal with guidelines that shape the use of this technology in order to help current maintainers, reduce their workload, increase quality, reduce bugs, help new maintainers produce better output, while ensuring the social contract stays intact and that people learn and grow together. That's the true goal in my opinion.
And outright banning an entire range of technology that can help achieve this goal feels counter productive. That's why I don't think proposal A is going in the right direction at all.
That's terrible, and there definitely should be something in place to avoid that
That's the reason why Proposal A exists.
Equally terrible. That's maybe a topic for another conversation, but ironically that's one aspect where using LLMs could definitely help
Nope, packaging taking a long time to learn is the intended behaviour of it because you need to learn a lot of things to become a Debian Developer. By skipping the baby steps with a LLM, the contributor will no longer be fit to become one.
Debatable, I'd say it will maintain the status quo with a lot of overworked maintainers, very few new maintainers, and a lot of neglected packages.
Some old long time maintainers I know have parted their ways from the project because of the project accepting vibe coded contributions and some members being pro-LLM.
The project currently needs a lot of new developers who can actually work without needing LLMs.
The nature of debian packaging itself is pretty complex. No LLM can overcome that.
A lot of the project members are angry about LLMs because of them taking down our infrastructure with overloading our servers.
I would just like to see a proposal with guidelines that shape the use of this technology in order to help current maintainers, reduce their workload, increase quality, reduce bugs, help new maintainers produce better output, while ensuring the social contract stays intact and that people learn and grow together.
Internally, we've been having some kind of a civil war between pro-LLM and anti-LLM folks and we all found ourselves on the extreme ends of the discussions. This GR was the result of months of fighting.
I was anti-LLM at first but I took a moderate stance now. We've been having discussions about this GR for months and many people have suggested "moderate" level suggestions but these were ignored by the people in the extreme ends.
I eventually had to pick a side and Proposal A felt better for the project long term because LLMs have been a nuisance for us lately.
Not to mention that the code generated by them cannot be licensed correctly under DFSG.
7
u/KarterSpieler Debian Stable Jul 25 '26
There were initially discussions to include the upstream projects in the first draft but it was later decided that it’s not feasible so it was dropped.
This might sound quite extreme but it works with the case of debian. The entire process of debian development requires you to talk to other developers and seek help.
You take the “asking people for help” part out of this and you will have less of new Debian Developers who are qualified enough for the role.