Hi all, I’d like to start a discussion among maintainers about a small process change aimed at reducing reviewer load.
Problem Review capacity is the scarcest resource in GCC. A large share of review rounds is spent on issues that could have been caught before the patch was posted: GNU style violations, missing or weak testcases, commit message and ChangeLog problems, unhandled corner cases, simple logic slips. When a patch needs three or four rounds to clear these, the cost falls on a small number of volunteer reviewers, and that is a direct path to burnout. Proposal Maintainers expect, and the contribution guidelines recommend, that submitters do the following before posting a patch for review: 1. Run the deterministic checks. That means contrib/check_GNU_style.sh, plus bootstrap and regression testing on a relevant target, as already required. 2. Run an AI-assisted review where available. Give the tool real context, not only the diff: the surrounding code, the relevant machine description or front-end code, and the testsuite results. Reviews of a bare diff are much shallower. 3. Own the result. The submitter is responsible for the patch and for judging the review output. Each finding must be checked against the code and documentation before acting on it, since tools are often wrong on subtle target, ABI or language-semantics details. Raw tool output should not be pasted into the thread. 4. Disclose briefly. A one-line note in the cover letter, for example “pre-reviewed with <tool>, findings verified manually”, is welcome and keeps with the transparency the AI policy discussions have asked for. 5. Mind confidentiality. Unposted security-sensitive or embargoed patches should not be sent to third-party services. What this is not * It is not a change to the GCC AI policy. AI review is assistance only and does not make AI-generated code acceptable where the policy does not allow it. * It is not a hard gate. Not everyone has access to such tools, and employers may restrict their use. No patch should be rejected solely for lacking a pre-review. * It does not replace human review. Design-level questions (is this the right approach, does it fit the architecture) still need maintainers. How maintainers might apply it Where a patch arrives with obvious issues that a pre-review would likely have found, a maintainer may reply once asking for a resend after such a check, instead of starting a full review round. Maintainers may also run an AI review themselves and forward the filtered findings to the author, which is what I currently do for i386 patches. Each area maintainer remains free to decide how strictly to apply this. Open questions * Should this go into the contribution guidelines (gcc.gnu.org/contribute.html), or stay a maintainer-level convention? * Does the steering committee want to weigh in, given the overlap with the recently announced AI policy? * Should we offer a short checklist of what context to provide to the tool? Feedback, objections and alternatives are welcome, especially from maintainers who have seen the cost of repeated review rounds firsthand. Thanks, Uros.
