Alex Crichton
5 years ago
6 changed files with 154 additions and 166 deletions
@ -1,13 +1,12 @@ |
|||||
# Contributing to Wasmtime |
# Contributing to Wasmtime and/or Cranelift |
||||
|
|
||||
Wasmtime is a [Bytecode Alliance] project, and follows the Bytecode Alliance's [Code of Conduct] and [Organizational Code of Conduct]. |
Wasmtime and Cranelift are [Bytecode Alliance] projects. They follow the |
||||
|
Bytecode Alliance's [Code of Conduct] and [Organizational Code of Conduct]. |
||||
|
|
||||
Wasmtime follows the same development style as Cranelift, so check out |
For more information about contributing to these projects you can consult the |
||||
[Cranelift's CONTRIBUTING.md]. Of course, for Wasmtime-specific issues, please |
[online documentation] which should cover all sorts of topics. |
||||
use the [Wasmtime issue tracker]. |
|
||||
|
|
||||
[Bytecode Alliance]: https://bytecodealliance.org/ |
[Bytecode Alliance]: https://bytecodealliance.org/ |
||||
[Code of Conduct]: CODE_OF_CONDUCT.md |
[Code of Conduct]: CODE_OF_CONDUCT.md |
||||
[Organizational Code of Conduct]: ORG_CODE_OF_CONDUCT.md |
[Organizational Code of Conduct]: ORG_CODE_OF_CONDUCT.md |
||||
[Cranelift's CONTRIBUTING.md]: https://github.com/bytecodealliance/cranelift/blob/master/CONTRIBUTING.md |
[online documentation]: https://bytecodealliance.github.io/wasmtime/contributing.html |
||||
[Wasmtime issue tracker]: https://github.com/bytecodealliance/wasmtime/issues/new |
|
||||
|
|||||
@ -1,151 +0,0 @@ |
|||||
# Contributing to Cranelift |
|
||||
|
|
||||
## Welcome! |
|
||||
|
|
||||
Cranelift is a very ambitious project with many goals, and while we're |
|
||||
confident we can achieve some of them, we see many opportunities for people |
|
||||
to get involved and help us achieve even more. |
|
||||
|
|
||||
### Ask questions! Give feedback! |
|
||||
|
|
||||
This is a relatively young project, and not everything we hope to do with it |
|
||||
is reflected in the code or documentation yet. If you see things that seem |
|
||||
missing or that don't make sense, or even that just don't work the way you |
|
||||
expect them to, we're interested to hear about it! |
|
||||
|
|
||||
We have a [stream] in the Bytecode Alliance Zulip instance, and questions are |
|
||||
also welcome as issues in the [Cranelift issue tracker]. |
|
||||
|
|
||||
[stream]: https://bytecodealliance.zulipchat.com/#narrow/stream/217117-cranelift/topic/general |
|
||||
[Cranelift issue tracker]: https://github.com/bytecodealliance/cranelift/issues/new |
|
||||
|
|
||||
### Mentoring |
|
||||
|
|
||||
We're happy to mentor people, whether you're learning Rust, learning about |
|
||||
compiler backends, learning about machine code, learning about how Cranelift |
|
||||
does things, or all together at once. |
|
||||
|
|
||||
We categorize issues in the issue tracker using a tag scheme inspired by |
|
||||
[Rust's issue tags]. For example, the [E-easy] marks good beginner issues, |
|
||||
and [E-rust] marks issues which likely require some familiarity with Rust, |
|
||||
though not necessarily Cranelift-specific or even compiler-specific |
|
||||
experience. [E-compiler-easy] marks issues good for beginners who have |
|
||||
some familiarity with compilers, or are interested in gaining some :-). |
|
||||
|
|
||||
See also the [full list of labels]. |
|
||||
|
|
||||
Also, we encourage people to just look around and find things they're |
|
||||
interested in. This a good time to get involved, as there aren't a lot of |
|
||||
things set in stone yet. |
|
||||
|
|
||||
[Rust's issue tags]: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage |
|
||||
[E-easy]: https://github.com/bytecodealliance/cranelift/labels/E-easy |
|
||||
[E-rust]: https://github.com/bytecodealliance/cranelift/labels/E-rust |
|
||||
[E-compiler-easy]: https://github.com/bytecodealliance/cranelift/labels/E-compiler-easy |
|
||||
[full list of labels]: https://github.com/bytecodealliance/cranelift/labels |
|
||||
|
|
||||
### Code of Conduct |
|
||||
|
|
||||
Cranelift is a [Bytecode Alliance] project, and follows the Bytecode Alliance's [Code of Conduct] and [Organizational Code of Conduct]. |
|
||||
|
|
||||
[Bytecode Alliance]: https://bytecodealliance.org/ |
|
||||
[Code of Conduct]: CODE_OF_CONDUCT.md |
|
||||
[Organizational Code of Conduct]: ORG_CODE_OF_CONDUCT.md |
|
||||
|
|
||||
## Coding Guidelines |
|
||||
|
|
||||
For the most part, Cranelift follows common Rust conventions and |
|
||||
[pull request] (PR) workflows, though we do have a few additional things to |
|
||||
be aware of. |
|
||||
|
|
||||
[pull request]: https://help.github.com/articles/about-pull-requests/ |
|
||||
|
|
||||
### rustfmt |
|
||||
|
|
||||
All PRs must be formatted according to rustfmt, and this is checked in the |
|
||||
continuous integration tests. We use the current stable [rustfmt-preview] |
|
||||
version. See the [rustfmt quickstart] for setup. |
|
||||
|
|
||||
[format-all.sh] is a script for running the appropriate version of rustfmt, |
|
||||
which may be convenient when there are multiple versions installed. |
|
||||
|
|
||||
[rustfmt-preview]: https://github.com/rust-lang/rustfmt |
|
||||
[rustfmt quickstart]: https://github.com/rust-lang/rustfmt#quick-start |
|
||||
[format-all.sh]: https://github.com/bytecodealliance/cranelift/blob/master/format-all.sh |
|
||||
|
|
||||
### Rustc version support |
|
||||
|
|
||||
Cranelift supports stable Rust, and follows the |
|
||||
[Rust Update Policy for Firefox]. |
|
||||
|
|
||||
Some of the developer scripts depend on nightly Rust, for example to run |
|
||||
clippy and other tools, however we avoid depending on these for the main |
|
||||
build. |
|
||||
|
|
||||
[Rust Update Policy for Firefox]: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox#Schedule |
|
||||
|
|
||||
## Development Process |
|
||||
|
|
||||
We use [issues] for asking questions and tracking bugs and unimplemented |
|
||||
features, and [pull requests] (PRs) for tracking and reviewing code |
|
||||
submissions. |
|
||||
|
|
||||
### 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 |
|
||||
change (and if it's difficult to summarize in one line, consider |
|
||||
splitting the change into multiple PRs), optionally followed by |
|
||||
additional context. Good things to mention include which areas of the |
|
||||
code are affected, which features are affected, and anything that |
|
||||
reviewers might want to pay special attention to. |
|
||||
|
|
||||
- If there is code which needs explanation, prefer to put the explanation in |
|
||||
a comment in the code, or in documentation, rather than in the commit |
|
||||
message. |
|
||||
|
|
||||
- For pull requests that fix existing issues, use [issue keywords]. Note that |
|
||||
not all pull requests need to have accompanying issues. |
|
||||
|
|
||||
- Assign the review to somebody from the [Core Team], either using suggestions |
|
||||
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 |
|
||||
logical commits (though keeping logical commits focused). Developers may do |
|
||||
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 |
|
||||
should pass at each logical commit. |
|
||||
|
|
||||
### Review and merge |
|
||||
|
|
||||
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/ |
|
||||
[pull requests]: https://help.github.com/articles/about-pull-requests/ |
|
||||
[issue keywords]: https://help.github.com/articles/closing-issues-using-keywords/ |
|
||||
[Core Team]: https://github.com/orgs/bytecodealliance/people/ |
|
||||
@ -0,0 +1,33 @@ |
|||||
|
# Coding guidelines |
||||
|
|
||||
|
For the most part, Wasmtime and Cranelift follow common Rust conventions and |
||||
|
[pull request] (PR) workflows, though we do have a few additional things to |
||||
|
be aware of. |
||||
|
|
||||
|
[pull request]: https://help.github.com/articles/about-pull-requests/ |
||||
|
|
||||
|
### rustfmt |
||||
|
|
||||
|
All PRs must be formatted according to rustfmt, and this is checked in the |
||||
|
continuous integration tests. You can format code locally with: |
||||
|
|
||||
|
```sh |
||||
|
$ cargo fmt |
||||
|
``` |
||||
|
|
||||
|
at the root of the repository. You can find [more information about rustfmt |
||||
|
online](https://github.com/rust-lang/rustfmt) too, such as how to configure |
||||
|
your editor. |
||||
|
|
||||
|
### Rustc version support |
||||
|
|
||||
|
Wasmtime supports the current stable version of Rust. |
||||
|
|
||||
|
Cranelift supports stable Rust, and follows the [Rust Update Policy for |
||||
|
Firefox]. |
||||
|
|
||||
|
Some of the developer scripts depend on nightly Rust, for example to run |
||||
|
clippy and other tools, however we avoid depending on these for the main |
||||
|
build. |
||||
|
|
||||
|
[Rust Update Policy for Firefox]: https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox#Schedule |
||||
@ -0,0 +1,66 @@ |
|||||
|
# Development Process |
||||
|
|
||||
|
We use [issues] for asking questions ([open one here][newissue]!) and tracking |
||||
|
bugs and unimplemented features, and [pull requests] (PRs) for tracking and |
||||
|
reviewing code submissions. |
||||
|
|
||||
|
### 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 |
||||
|
change (and if it's difficult to summarize in one line, consider |
||||
|
splitting the change into multiple PRs), optionally followed by |
||||
|
additional context. Good things to mention include which areas of the |
||||
|
code are affected, which features are affected, and anything that |
||||
|
reviewers might want to pay special attention to. |
||||
|
|
||||
|
- If there is code which needs explanation, prefer to put the explanation in |
||||
|
a comment in the code, or in documentation, rather than in the commit |
||||
|
message. |
||||
|
|
||||
|
- For pull requests that fix existing issues, use [issue keywords]. Note that |
||||
|
not all pull requests need to have accompanying issues. |
||||
|
|
||||
|
- Assign the review to somebody from the [Core Team], either using suggestions |
||||
|
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 |
||||
|
logical commits (though keeping logical commits focused). Developers may do |
||||
|
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 |
||||
|
should pass at each logical commit. |
||||
|
|
||||
|
### Review and merge |
||||
|
|
||||
|
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/ |
||||
|
[pull requests]: https://help.github.com/articles/about-pull-requests/ |
||||
|
[issue keywords]: https://help.github.com/articles/closing-issues-using-keywords/ |
||||
|
[Core Team]: https://github.com/orgs/bytecodealliance/people/ |
||||
|
[newissue]: https://github.com/bytecodealliance/wasmtime/issues/new |
||||
Loading…
Reference in new issue