OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
gcc/CONTRIBUTING.md

50 lines
2.6 KiB
Markdown
Raw Normal View History

Create CONTRIBUTING.md This provides context for people learning to submit code or issues back to the project. It will help answer frequently asked questions and a set of rules for all of us to follow. This is something that should evolve over time.
2021-04-15 11:35:41 +02:00
## How to contribute to GCC Rust
#### **Did you find a bug?**
* **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/Rust-GCC/gccrs/issues).
* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/Rust-GCC/gccrs/issues/new). Be sure to include a **title and clear description**, as much relevant information as possible, and a **code sample** or an **executable test case** demonstrating the expected behavior that is not occurring.
Update CONTRIBUTING.md We have been accepting patches via mail from developers following the normal GCC processes. Let's update our guidelines to reflect this. Co-authored-by: CohenArthur <arthur.cohen@epita.fr> Co-authored-by: Thomas Schwinge <thomas@codesourcery.com> Co-authored-by: Miguel Ojeda <ojeda@users.noreply.github.com>
2021-05-28 14:22:12 +02:00
#### **Do you want to submit a patch?**
Create CONTRIBUTING.md This provides context for people learning to submit code or issues back to the project. It will help answer frequently asked questions and a set of rules for all of us to follow. This is something that should evolve over time.
2021-04-15 11:35:41 +02:00
* Open a new GitHub pull request with the patch.
* Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
Some polishing of DCO wording <https://github.com/Rust-GCC/gccrs/pull/730/files#r728027852>.
2021-10-14 10:35:24 +02:00
* Before submitting, GCC development requires copyright assignment or the Developer's Certificate of Origin sign-off. Please see the [Contributing to GCC](https://gcc.gnu.org/contribute.html) guide or [Developer's Certificate of Origin (DCO) Sign-off](https://gcc.gnu.org/dco.html) guide.
Create CONTRIBUTING.md This provides context for people learning to submit code or issues back to the project. It will help answer frequently asked questions and a set of rules for all of us to follow. This is something that should evolve over time.
2021-04-15 11:35:41 +02:00
Update CONTRIBUTING.md We have been accepting patches via mail from developers following the normal GCC processes. Let's update our guidelines to reflect this. Co-authored-by: CohenArthur <arthur.cohen@epita.fr> Co-authored-by: Thomas Schwinge <thomas@codesourcery.com> Co-authored-by: Miguel Ojeda <ojeda@users.noreply.github.com>
2021-05-28 14:22:12 +02:00
* Patches sent to the [`gcc-rust` mailing list](https://gcc.gnu.org/mailman/listinfo/gcc-rust) are likewise welcome.
These will be imported into a GitHub PR to follow the normal review process, and the link to the GitHub PR sent to the submitter.
Create CONTRIBUTING.md This provides context for people learning to submit code or issues back to the project. It will help answer frequently asked questions and a set of rules for all of us to follow. This is something that should evolve over time.
2021-04-15 11:35:41 +02:00
#### **Do you intend to add a new feature or change an existing one?**
* Suggest your change in the [Zulip](https://gcc-rust.zulipchat.com/) and start writing code.
* Do not open an issue on GitHub until you have collected positive feedback about the change. GitHub issues are primarily intended for bug reports and fixes.
#### **Do you have questions about the source code?**
* Ask any question about how to use GCCRS in [Zulip](https://gcc-rust.zulipchat.com/).
### **PR Policy**
* The PR policy: Everything has to go through a PR
- An exception to this rule will be the merge commits of updating the repo against upstream GCC
* Reviewers/Maintainers of the project (aka people who have bors rights) should be pinged for reviews/questions.
* A PR can have one or several commits (split should have a technical/logical reason, ie. no fixup-ish commit)
* Avoid PR's with merge commit unless there's a good reason
Re-organize GCC/Rust testsuites ... as discussed in <https://gcc-rust.zulipchat.com/#narrow/stream/266897-general/topic/Testsuite.20results>: > [...] best practice from what other GCC testsuites are doing), which I hope > makes clearer the difference between the individual GCC/Rust testsuites: > 'rust.test/compile' -> 'rust/compile/torture' > 'rust.test/execute' -> 'rust/execute/torture' > 'rust.test/unsupported' -> 'rust/compile/xfail' > 'rust.test/xfail_compile' -> 'rust/compile' ... plus corresponding documentation updates in the '*.exp' files and elsewhere.
2021-06-02 11:05:44 +02:00
* Where possible please add test cases to `gcc/testsuite/rust/` for all PRs. Some issues may not be testable via dejagnu/automation such as debug dump changes.
Create CONTRIBUTING.md This provides context for people learning to submit code or issues back to the project. It will help answer frequently asked questions and a set of rules for all of us to follow. This is something that should evolve over time.
2021-04-15 11:35:41 +02:00
* PR's cannot be merged untill clang format and the build and tests pass.
* Please take the time to create good git commit messages see the existing format of them in the git log or refer to something like: https://chris.beams.io/posts/git-commit/
Thanks! :heart: :heart: :heart:
GCCRS Team