On Wed, Oct 21, 2026, 4:43 AM Uros Bizjak via Gcc <[email protected]> wrote:
> 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: > No because this huge burden on first time folks. See below. > 1. Run the deterministic checks. That means > contrib/check_GNU_style.sh, plus bootstrap and regression testing on a > relevant target, as already required. > 1 is fine. > 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. > NO. We should not expect this at all. Especially from students or hobbiests. And in fact it goes against free software depending on closed source at all. > > > > > 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. > Now owning the patch and such is part of being a contributor but you as a maintainer have a responsibility to help mentor folks in growing. If folks are not learning that is a different story but I have not seen that. > 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. > Ahain this is a crap part of this proposal. Now we should be mentoring folks into being able to read the source and documentation and understanding it. Now if folks ask for a review posting we should accept that rather than pushing them off to a machine and make it sound like we dont care. > > > > > 5. Mind confidentiality. Unposted security-sensitive or embargoed > patches should not be sent to third-party services. > Huh? There is no confidential patches being posted. Did you use AI to help write this because this throws off the whole proposal in odd direction. > 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. >
