On Mon, Nov 9, 2026 at 3:41 AM Lucas Nussbaum <[email protected]> wrote:
> On 07/11/26 at 13:56 +0000, Ian Jackson wrote: > > But these message *do not* satisfy *any* standards of quality and > > correctness, and *no-one* takes responsibility for them. > > > > The use of generative AI does not alter Debian's established > > expectations regarding large-scale or automated project > > actions. Contributors intending to perform actions with broad > > project impact, such as mass bug filing or patch submission, > > large-scale code modifications, or other automated changes or > > requests affecting many packages or contributors, should seek prior > > discussion and consensus through the appropriate project channels > > before proceeding. ... > > > > The new system is clearly a "large-scale or automated" project action. > > What is the *action* you are referring to? > > The DFSG team decided to use a tool to help them with reviews. > They decided to share the tool's output with the uploader, so that the > uploader can comment or use the tool's output to improve their package, > if relevant, and if they chose to (there's no obligation to look at the > tool's output). > > The only action I see is sending an email to notify uploaders of the > availability of the tool's output, but this has been made opt-out. > > So, really, I don't see what's this all about, if it's not about bashing > people that use LLM. > This matches my position pretty well. On Ian's points: Accountability for NEW queue processing rests squarely on the human reviewer driving the dnq tool. The LLM output is a supplementary signal, exposed to uploaders purely for transparency. The individual human reviewer sets and upholds the quality standards, taking full, personal responsibility for every final verdict. Modifying internal team infrastructure is fundamentally different from mass automated actions that blindly impact the archive. Historically, Debian teams do not hold votes or consult the broader project on how to build, tune, and deploy their own backend tools for their delegated workloads. The notable recent exception to this norm was tag2upload. As that experience demonstrated, trying to design and approve infrastructure details via project-wide consensus and General Resolutions is an incredibly heavy lift that takes a real toll on the community. While we absolutely regret the friction our unannounced rollout caused, requiring a project-wide mandate just to iterate on internal team tooling sets an unsustainable precedent for getting work done in Debian. -rt
