RE: On pull request workflows for the GNU toolchain

["Jiang, Haochen via Gdb" <gdb@sourceware.org>]

> From: Joseph Myers <josmyers@redhat.com>
> Sent: Wednesday, September 25, 2024 12:43 AM
> 
> On Tue, 24 Sep 2024, Jiang, Haochen via Gcc wrote:
> 
> Where projects have existing pre-commit CI that puts CI results in
> patchwork based on patches processed there, I hope such CI would be
> updated to work with pull requests and update the pull requests with such
> CI results.
> 
> > > Beyond putting everything through PRs, eventually I'd hope to have
> > > merges to mainline normally all go through a CI system that makes sure
> > > there are no regressions for at least one configuration before merging
> > > changes.
> > >
> >
> > CI might take long time if not just building but running regression tests
> > from my current experience, it might cause some inconvenience for
> > someone who only edits something like MAINTAINER lists.
> 
> MAINTAINERS list updates are not urgent, it should be fine for them to
> wait for a batch of approved PRs to pass CI.  (The commit rate in GCC is
> sufficient, and testing sufficiently slow, that I expect a CI system
> managing merges would need to test potential commits to mainline as a
> batch rather than testing every individual commit before it goes in
> mainline.)

Aha, that is currently what arm and us are doing. Seems that won't change
most of the workflow. Actually, I am happy with directly sending the
regression to the exact PR, it will be much clearer.

The potential issue might be the PR will be closed after merging, which might
be flooded in history if the regression is not fixed with the PR forgotten to be 
reopened. I am not sure the reopen could be automatically done. If it could,
it will be great, or I will still also send a mail to the mailing thread to record
them explicitly just like how we does currently in gcc-patches and
gcc-regression mailing thread.

Thx,
Haochen