On Wed, Oct 21, 2026 at 1:58 PM Andrew Pinski <[email protected]> wrote: > > > > 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.
Just FYI, I have done all my reviews in the last month or so with the help of AI. With great success. For zero cost. I *am* a hobbyist with a limited time, so I guess I can expect the same approach from other hobbyists. I don't care if the tool usage, open or closed source, goes against some philosophy, it is a *tool* that makes my life easier. Or ... should I also walk around because my car uses closed source? So, if I declare that I care for my wellbeing and that "I don't plan to review any patches without AI pre-review", what will happen? > >> >> 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. Not at all, and I strongly disagree. I have the responsibility for the code quality. I am an unpaid volunteer, interested in compiler tech, and I certainly don't have time and will to mentor folks. >> 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. Patches are not the way to mentor people. We have summer-of-code for this. Patches are expected to be the final form of a code that implements desired functionality. And BTW: Did you actually see the code review that Claude performs? Can you use it to self-mentor? >> 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. Sure, written with the help of AI, a tool under my command, that does things better. This point slipped through. Please ignore. Uros.
