The voting seems to have been pretty much linear to how pro-LLM they were. So it's interesting that all of the proposals were essentially anti-LLM and the chosen one was the mostly neutral, only slightly anti-LLM one. The absence of any pro-LLM proposal indicated that proposal writers are not in sync with the voters

▲

nekiwo a day ago | parent | next [-]

The voters here are people active on the mailing list, not general users of Debian or LLM automated PR contributors.

▲

Palomides a day ago | parent | prev | next [-]

the way you phrase this implies some sort of suppression of LLM interest, but anyone eligible to vote on these could have made their own. The absence of pro-LLM proposals shows nobody wanted one enough to send an email or two about it.

▲

eterm a day ago | parent | prev [-]

What would "pro-LLM" look like to you?

▲

dooglius a day ago | parent [-]

Ex: Security-critical code contributions should be scrutinized via state of the art tooling, including but not limited to fuzzers, linters, and adversarial LLM review. For non-security-critical code, use of LLMs is encouraged but not required. The bar for code quality should be raised as the skills of coding agents increase; a developer's choice not to use LLMs is no excuse for miskates that an LLM would catch.

▲

eterm a day ago | parent | next [-]

That's an interesting opinion, and I certainly won't downvote you for sharing it, although it's not a position I would ever support. You are right though, that it would strengthen the voted-on position if there were more options either side of the position.

I have Things To Say about LLM reviews.

They are an endless grind. My biggest source of burnout right now is never being able to finish anything, because the LLM always finds, "Just one more thing" every time I send it back.

It's pure polish. The major issues were dealt with long ago. But there's always one more thing that could be done a little better, there's another niche edge case that needs wrapping up.

When human developer time was the limiting factor, it was easy to draw a line in the sand and say enough is enough.

It's harder to say no when it's just one more prompt and one more go-around.

Demanding LLM reviews on volunteer maintainers sounds like a great way to quickly end up with no maintainers.

▲

dooglius a day ago | parent [-]

I'm not advocating for this, but it's a example of a position reasonable enough I'd expect to see some level of support for. I'd view it as less extreme, for example, than requiring all new security-relevant code be in Rust, which is certainly something I've seen argued for in various contexts.

	▲	eterm a day ago \| parent [-]
		While not "only Rust", that development should be done in memory safe languages is the position of the US Government: Held both weakly by CISA: https://www.cisa.gov/resources-tools/resources/memory-safe-l... And more strongly by the NSA: > NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection C/C++ and assembly, to a memory safe language when possible. Some examples of memory safe languages are Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, and Ada. From https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

▲

tambre a day ago | parent | prev [-]

Meanwhile there's unfortunately still plenty of maintainers refusing to use version control systems...