RE: On pull request workflows for the GNU toolchain

Joseph Myers via Gdb
2024-09-24T16:44:23Z

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
josmyers@redhat.com