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.
