On 23/09/2026 14:46, Yuao Ma via Gcc wrote: > On Wed, Sep 23, 2026 at 9:38 PM Jonathan Wakely <[email protected]> wrote: >> >> On Wed, 23 Sept 2026 at 14:34, Yuao Ma <[email protected]> wrote: >>> >>> On Wed, Sep 23, 2026 at 6:48 PM Claudio Bantaloukas >>> <[email protected]> wrote: >>>> >>>> On 22/09/2026 16:59, Yuao Ma wrote: >>>>> Hi! >>>>> >>>>> Currently, while the forge experiment allows us to conduct code >>>>> reviews and run CI, landing approved patches still requires pushing >>>>> manually via the CLI. >>>>> >>>>> I am wondering if we could enable the bot account to push/merge >>>>> patches on our behalf. A good precedent for this is OpenJDK's >>>>> workflow, which uses the Skara bot (open-sourced at >>>>> https://github.com/openjdk/skara). For example, contributors can >>>>> trigger integration directly from the PR interface: >>>>> >>>>> https://github.com/openjdk/jdk/pull/32721#issuecomment-5749064779 >>>>> >>>>> Could we explore doing something similar here? Thoughts and feedback >>>>> are welcome. >>>> >>>> Hi Yuao, >>>> thank you for your interest in gcc development and the use of the forge >>>> for making your contributions. >>>> >>>> In the past year me and others tried to bridge contributions on the >>>> forge with the mailing list by making sure that everything done on the >>>> forge gets emailed. Some hiccups occurred but it seems to me that the >>>> process has been working well enough for a while now. I'd love to get >>>> feedback that this is not the case so I can address it BTW. >>>> >>>> With that in place, the question becomes how to get more value out of >>>> the forge by making it easier to merge changes done there with minimal >>>> interaction. >>>> >>>> This is IMO one of the main reasons why more people are not engaging >>>> with the forge. It makes little sense to use a web based system only to >>>> then have to manually merge the patches on the git repo. The missing >>>> value is the ability to merge (that is, do a fast forward and then >>>> merge, failing in the presence of conflicts, perhaps running some basic >>>> smoke tests before the final merge) with a single command, that should >>>> ideally be a single click on the UI or invoking "fj pr merge". >>>> >>>> Thank you for the link to the openjdk bot. It has some interesting ideas >>>> on commands that are possible with an automation like the one we have. >>>> The issues we face though are not purely technical. There are many bots >>>> that do merge trains and batrachomyomachia could do the same thing. The >>>> question is one of trust: is the gcc community happy with a bot doing >>>> merges for them? would they accept automatic rebases? what about rebases >>>> in the presence of signed commits? >>> >>> Thanks for the detailed explanation! You definitely brought up a few >>> points I hadn’t considered. Regarding that specific concern, though, >>> could we make this an optional feature for people that want it? >>> Ultimately, a committer has to explicitly trigger the bot anyway, so >>> the existing workflow would remain completely unaffected. >> >> Maybe only project owners (or at least project members) should be able >> to trigger that push. If we want to move away from having hundreds of >> people with ssh access and git commit access on sourceware, then the >> workflow should not rely on the person creating the pull request also >> having commit-over-ssh access to the main repo. >> > > I agree. Ideally, the MAINTAINERS file would be transitioned into a > CODEOWNERS file, requiring PRs to receive code owner approval > alongside sponsorship from a committer. Though I'm not certain how > neatly that maps to project membership roles.
That process has already begun. The MAINTAINERS file is now auto-generated from MAINTAINERS.yml and the reason for doing that was to get the data into a form where we can use it for generating other material needed for various types of automation. CODEOWNERS is one such example, but there's also the contrib/forge_teams.py script which repo administrators can use to manage teams in the forge. R.
