RE: On pull request workflows for the GNU toolchain

On Tue, 24 Sep 2024, Jiang, Haochen via Gcc wrote:

> I am running regression tests on x86_64 and sending the regressions to
> gcc-regression mailing thread, will I need to send to another place or
> using another API to do that?

I don't expect use of pull requests to change anything about existing 
regression processing that uses mailing lists.  (Systems such as Linaro's 
that identify a specific commit responsible for a regression might wish to 
update the PR accordingly using whatever API is available for posting 
comments on PRs.)

Note the recent discussion of making contrib/test_summary able to submit 
test results to bunsen.

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.)

> Another question is should we also open a PR for backport commits?

I've left that question open.  I'd hope mainline would eventually move to 
everything going via PRs; other development branches people might freely 
continue to commit directly to, though with the option of using PRs to 
such a branch if the branch maintainers find it useful; and for release 
branches we'd need to consider the best process separately.

> Also for the current commit for obvious, will that policy change?

I wouldn't expect such a policy to change.  With a system of everything 
going through PRs, that would mean anyone with write access could 
approve and merge their own PRs that meet the obvious rule.

-- 
Joseph S. Myers
[email protected]