Since we've now upstreamed the frontend to GCC's master branch, and are slowly but surely coming to terms with #1705 and writing all the missing Changelogs, we need to figure out how to move forward. I want this issue, similarly to #1705, to serve as a discussion for how to proceed with this.
I think one of the most impressive achievements of this project has been how everyone involved has managed to create a welcoming environment and a warm entrypoint to GCC overall. In my opinion, we should strive to keep that up and keep this repository as welcoming as possible.
To do so, and taking into account that our commits now need to conform to a specific format, we should add more automation to our CIs in order to gently enforce these new rules.
I think some good starting points for discussion would be the following:
[ ] Enforce Changelogs on all commits of a pull-request
[ ] Enforce DCO signoff/FSF copyright assignment for all contributors after a certain amount of contributions
[ ] Reflect those changes on the various github templates and CONTRIBUTING.md file
[ ] Add bootstrap build and test checks for each commit after a PR has been approved
[ ] Switch to github merge queues
[ ] git gcc-commit-mklog -s is broken and puts the SoB line above the Changelog
A very good starting point from @philberty is https://github.com/Rust-GCC/gccrs/pull/1738. We're now using that check for all PRs targeting gcc-patch-dev and testing it in the wild. It's in a good state and I'd like to make it a little more interactive for new contributors, as well as for project managements.
Since we've now upstreamed the frontend to GCC's master branch, and are slowly but surely coming to terms with #1705 and writing all the missing Changelogs, we need to figure out how to move forward. I want this issue, similarly to #1705, to serve as a discussion for how to proceed with this.
I think one of the most impressive achievements of this project has been how everyone involved has managed to create a welcoming environment and a warm entrypoint to GCC overall. In my opinion, we should strive to keep that up and keep this repository as welcoming as possible.
To do so, and taking into account that our commits now need to conform to a specific format, we should add more automation to our CIs in order to gently enforce these new rules.
I think some good starting points for discussion would be the following:
git gcc-commit-mklog -s
is broken and puts the SoB line above the ChangelogA very good starting point from @philberty is https://github.com/Rust-GCC/gccrs/pull/1738. We're now using that check for all PRs targeting
gcc-patch-dev
and testing it in the wild. It's in a good state and I'd like to make it a little more interactive for new contributors, as well as for project managements.