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