Debian Votes Responsible Generative AI Use: How-To Guide

The #1 Mistake After Debian Votes to Allow Responsible Use of Generative AI

People treat the fresh GR result like a free pass: dump a half-baked ChatGPT patch or d/rules snippet straight into a package upload or salsa MR. That is exactly the failure mode the winning text flags.

Voting closed 28 August 2026. Choice 5 – “Responsible Use of Generative AI” (Marc Haber) – landed as Condorcet winner. Per the official GR page, Debian neither endorses nor prohibits generative AI for packaging, code, docs, or other media. Same quality, correctness, maintainability, and legal bar. You still own the upload.

Reverse the mistake. Draft with tools if you want. Then understand → review → test → modify before anything leaves your machine.

Quick Context: What the Vote Actually Changed

Several ballot options ran from hard bans to conditioned allow rules. Option 5 beat the next strongest permit option 203-148 and beat the tighter ones by wider pairwise margins (official tally on the same vote page). Ban options never cleared the supermajority bar.

What actually binds you (full text on the vote page; also walked through by Phoronix): understand, review, test, and modify AI output as needed before you incorporate it. Disclosure of assistance is encouraged, not mandatory. Large-scale automation still needs prior project discussion and a named human owner. Copyright and training-data questions stay unresolved – existing DFSG and licensing rules still apply, so provenance is your problem.

Reactions split hard. Some DDs liked the accountability framing. At least one DD publicly stepped back over the outcome. The statement sits under Constitution 4.1(5) and can evolve later without another full GR.

Hands-On: Responsible Workflow with DebGPT and Local Backends

DebGPT is the Debian-shaped tool most news write-ups skip. As of August 2026 it is packaged for Debian and on PyPI: Policy/devref/BTS/buildd/sbuild/git readers, local ZMQ plus OpenAI-compatible backends, inplace edit, mapreduce for long logs. See the DebGPT manpage.

sudo apt install debgpt # or pip3 install debgpt
debgpt config # writes ~/.config/debgpt/config.toml
# OPENAI_API_KEY for cloud, or point at local / ZMQ

Config took me two tries the first time – wrong endpoint URL, empty reply, no useful error. Worth a dry run on a public manpage before you touch a real package.

Non-public tree? Local backend (Ollama, llama.cpp, DebGPT ZMQ). Cloud only for material that is already public.

Step 1 – Draft with context, never from a blank prompt

Feed real Debian sources instead of hoping the model remembers Policy:

# Packaging snippet against current Policy
debgpt -Hf debian/ -Hf policy: -a 'Does this d/rules handle Multi-Arch correctly? Suggest a minimal fix only.'

# Staged diff → commit message
debgpt -Hf cmd:'git diff --staged' -A 'Write a concise DEP-3 style commit message and note any Policy risks.'

# Long build log via mapreduce
debgpt -Hx sbuild: -A 'Why did the build fail on arm64? List concrete fixes.'

-H hides the huge assembled prompt. -x chunks MapReduce when the log blows past context.

Step 2 – Force the human review loop

1. Read every line. Can you explain why each change is correct?
2. Real checks: lintian -EviIL +pedantic, sbuild or pbuilder, autopkgtest, local rebuild.
3. Edit ruthlessly. Kill hallucinated watch files, imaginary copyright holders, stale overrides.
4. Optional: one changelog/commit line – “assisted by DebGPT + Claude; fully reviewed”.

Think of the model as a noisy junior who has skimmed every list archive and never signed an upload. You still sign. You still eat the RC bug.

Step 3 – In-place edits when you trust the loop

debgpt -Hi debian/control -a 'Add Build-Depends on libfoo-dev for the new feature; keep formatting.' --inplace

Stage, re-read the diff, then commit yourself. Skip that pause on archive-bound work and you are back at the #1 mistake.

Honest question nobody can answer from the GR text alone: will your sponsor treat an unlabeled AI-assisted diff colder than a hand-typed one? Disclosure is optional on paper. In practice, a one-liner often costs less than a long review argument.

Common Pitfalls That Still Bite

What Results Actually Look Like

First draft of a manpage section. A starter d/watch. A commit message you still rewrite twice. That is the upside – less blank-page time, not higher archive quality. Lintian noise stays. Sponsor push-back stays. The bar did not move.

Local backends: slower, no third-party paste risk. Cloud: snappier on public docs, every prompt needs a scrub.

When Not to Reach for Generative AI

Embargo windows. Private debian-* traffic. Keys and credentials. Bulk actions nobody agreed to on-list. And any output you could not defend on IRC at 2am – that defense is the standard now. New contributors who lean on models without learning Policy still dump review work on sponsors; the GR did not erase that social cost.

FAQ

Do I have to label AI-assisted uploads?

No. Encouraged only. Many people add a one-liner anyway.

Can I use GitHub Copilot or Claude on a packaging branch?

You are mid-branch, public sources only, autopkgtest green after your edits. Yes – under the new position – if you fully own the diff and never paste non-public material. Sensitive bits in the tree? DebGPT against a local backend is the boring safe path. DFSG and copyright checks do not get a free pass.

What if a maintainer rejects my AI-touched patch on principle?

They can. The GR does not create an accept-AI obligation and does not add a special rejection code either. Maintainers and teams keep ordinary discretion; day-to-day judgment was left with humans on purpose. Misreading the vote as “AI patches must land” starts needless fights. Argue the technical merit on the list, or find another sponsor.

Read the official text once. Install DebGPT. Run one real packaging task end-to-end with the review gate. That single loop beats another news summary.