On Wed, Oct 21, 2026 at 2:41 PM Uros Bizjak via Gcc <[email protected]> wrote: > > 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?
I'm also using LLM review on my own patches with success (on company cost, not zero cost). I've been pointed to by Jeff to https://gcc.sashiko.dev/ which monitors gcc-patches - so that's only post-send LLM review, but still helpful to reviewers [cost]. > >> > >> 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? I found LLMs ability to prototype changes helpful saving time to navigate areas of GCC I do not know thoroughly (but only know "there must be functionality X somewhere"); the LLM prototype itself then helps reviewing exactly the portion of the code that matters. On the original topic I'd not put LLM review down as absolute requirement but as a suggestion to augment self-learning. > >> 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.
