You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
67 lines
3.0 KiB
67 lines
3.0 KiB
5 years ago
|
# 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
|