> From: Joseph Myers <josmy...@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
