On pull request workflows for the GNU toolchain
Joseph Myers
josmyers@redhat.com
Tue Sep 24 16:42:52 GMT 2024
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
More information about the Gdb
mailing list