I wonder how they can reconcile the stricter proposals with the LLM usage in kernel development. That seems totally untenable. I mean it all seems untenable, but with the kernel especially.

Also, what about when you inevitably get a situation where a critical vulnerability is discovered, and the only patch available is LLM generated? Do they have to wait to patch until some person who hasn't seen the LLM-generated patch does a clean room implementation?

I understand the objections to LLMs, but rejecting LLM-generated code really doesn't seem realistic.

▲

simonw 6 hours ago | parent | next [-]

Kernel development is excluded from this, because it's covered by "Upstream projects using LLMs for development".

On security, I worry that proposal A's "forbid any contributions to Debian written with the use or assistance of large language models", as written, excludes contributions where the LLM assisted in discovering the vulnerability. That's clearly a bad policy, and they should update their wording to clarify that.

▲

yjftsjthsd-h 5 hours ago | parent | next [-]

I read the question more as, if AI is working out for the kernel, why not a distro? (This is a question with valid answers, like the kernel having more devs paid to handle things while maintaining quality, but it's a fair question)

▲

aspensmonster 5 hours ago | parent | prev [-]

Isn't basically every package in Debian an upstream project?

	▲	simonw 4 hours ago \| parent [-]
		They're talking about the software that is unique to Debian, like their lintian tool. https://wiki.debian.org/Lintian

▲

bradfa 6 hours ago | parent | prev [-]

The proposals which say no LLM generated code mean just for Debian, if upstream allows it then they will still accept it. It’s just contributions to Debian itself which would prohibit or discourage LLM contributions.