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.
