T0b1/wasmtime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[contribution] Update contribution guidelines.

Browse Source
This commit is contained in:
Benjamin Bouvier
2019-10-17 17:39:44 +02:00
parent 499413dbc4
commit 873465e7a9
1 changed files with 34 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
cranelift/CONTRIBUTING.md
View File

@@ -69,8 +69,8 @@ version. See the [rustfmt quickstart] for setup.
[format-all.sh] is a script for running the appropriate version of rustfmt, [format-all.sh] is a script for running the appropriate version of rustfmt,
which may be convenient when there are multiple versions installed. which may be convenient when there are multiple versions installed.
[rustfmt-preview]: https://github.com/rust-lang-nursery/rustfmt [rustfmt-preview]: https://github.com/rust-lang/rustfmt
[rustfmt quickstart]: https://github.com/rust-lang-nursery/rustfmt#quick-start [rustfmt quickstart]: https://github.com/rust-lang/rustfmt#quick-start
[format-all.sh]: https://github.com/CraneStation/cranelift/blob/master/format-all.sh [format-all.sh]: https://github.com/CraneStation/cranelift/blob/master/format-all.sh
### Rustc version support ### Rustc version support
@@ -90,7 +90,20 @@ We use [issues] for asking questions and tracking bugs and unimplemented
features, and [pull requests] (PRs) for tracking and reviewing code features, and [pull requests] (PRs) for tracking and reviewing code
submissions. submissions.
When submitting PRs: ### Before submitting a PR
Consider opening an issue to talk about it. PRs without corresponding issues
are appropriate for fairly narrow technical matters, not for fixes to
user-facing bugs or for feature implementations, especially when those features
might have multiple implementation strategies that usefully could be discussed.
Our issue templates might help you through the process.
### When submitting PRs
- Please fill in the pull request template as appropriate. It is usually
helpful, it speeds up the review process and helps understanding the changes
brought by the PR.
- Write clear commit messages that start with a one-line summary of the - Write clear commit messages that start with a one-line summary of the
change (and if it's difficult to summarize in one line, consider change (and if it's difficult to summarize in one line, consider
@@ -106,8 +119,14 @@ When submitting PRs:
- For pull requests that fix existing issues, use [issue keywords]. Note that - For pull requests that fix existing issues, use [issue keywords]. Note that
not all pull requests need to have accompanying issues. not all pull requests need to have accompanying issues.
Anyone may submit a pull request, and anyone may comment on or review others' - Assign the review to somebody from the [Core Team], either using suggestions
pull requests. Pull requests are merged by members of the [Core Team]. in the list proposed by Github, or somebody else if you have a specific
person in mind.
- When updating your pull request, please make sure to re-request review if
the request has been cancelled.
### Focused commits or squashing
We generally squash sequences of incremental-development commits together into We generally squash sequences of incremental-development commits together into
logical commits (though keeping logical commits focused). Developers may do logical commits (though keeping logical commits focused). Developers may do
@@ -115,8 +134,16 @@ this themselves before submitting a PR or during the PR process, or Core Team
members may do it when merging a PR. Ideally, the continuous-integration tests members may do it when merging a PR. Ideally, the continuous-integration tests
should pass at each logical commit. should pass at each logical commit.
Core Team members may push minor changes directly, though should create PRs ### Review and merge
for significant changes.
Anyone may submit a pull request, and anyone may comment on or review others'
pull requests. However, one review from somebody in the [Core Team] is required
before the Core Team merges it.
Even Core Team members should create PRs for every change, including minor work
items (version bump, removing warnings, etc.): this is helpful to keep track of
what has happened on the repository. Very minor changes may be merged without a
review, although it is always preferred to have one.
[issues]: https://guides.github.com/features/issues/ [issues]: https://guides.github.com/features/issues/
[pull requests]: https://help.github.com/articles/about-pull-requests/ [pull requests]: https://help.github.com/articles/about-pull-requests/