1# Development Process 2 3We use [issues] for asking questions ([open one here][newissue]!) and tracking 4bugs and unimplemented features, and [pull requests] (PRs) for tracking and 5reviewing code submissions. We triage new issues at each of our bi-weekly 6[Wasmtime meetings][meetings]. 7 8### Before submitting a PR 9 10Consider opening an issue to talk about it. PRs without corresponding issues 11are appropriate for fairly narrow technical matters, not for fixes to 12user-facing bugs or for feature implementations, especially when those features 13might have multiple implementation strategies that usefully could be 14discussed. Changes that will significantly affect stakeholders should first be 15proposed in an [RFC](./contributing-rfc-process.md). 16 17Our issue templates might help you through the process. 18 19### When submitting PRs 20 21 - Please answer the questions in the pull request template. They are the 22 minimum information we need to know in order to understand your changes. 23 24 - Write clear commit messages that start with a one-line summary of the 25 change (and if it's difficult to summarize in one line, consider 26 splitting the change into multiple PRs), optionally followed by 27 additional context. Good things to mention include which areas of the 28 code are affected, which features are affected, and anything that 29 reviewers might want to pay special attention to. 30 31 - If there is code which needs explanation, prefer to put the explanation in a 32 comment in the code, or in documentation, rather than in the commit message. 33 Commit messages should explain why the new version is better than the old. 34 35 - Please include new test cases that cover your changes, if you can. If you're 36 not sure how to do that, we'll help you during our review process. 37 38 - For pull requests that fix existing issues, use [issue keywords]. Note that 39 not all pull requests need to have accompanying issues. 40 41 - When updating your pull request, please make sure to re-request review if 42 the request has been cancelled. 43 44### Focused commits or squashing 45 46We are not picky about how your git commits are structured. When we merge your 47PR, we will squash all of your commits into one, so it's okay if you add fixes 48in new commits. 49 50We appreciate it if you can organize your work into separate commits which each 51make one focused change, because then we can more easily understand your 52changes during review. But we don't require this. 53 54Once someone has reviewed your PR, it's easier for us if you _don't_ rebase it 55when making further changes. Instead, at that point we prefer that you make new 56commits on top of the already-reviewed work. 57 58That said rebasing (or merging from `main`) may still be required in situations 59such as: 60 61* Your PR has a merge conflict with the `main` branch. 62* CI on your PR is failing for unrelated reasons and a fix was applied to `main` 63 which needs to be picked up on your branch. 64* Other miscellaneous technical reasons may cause us to ask for a rebase. 65 66If you need help rebasing or merging, please ask! 67 68### Review and merge 69 70Anyone may submit a pull request, and anyone may comment on or review others' 71pull requests. However, one approval from a maintainer is required before a PR 72can be merged. Maintainers must also create PRs and get review from another 73maintainer for every change, including minor work items such as version bumps, 74removing warnings, etc. 75 76PR approvals may come with comments about additional minor changes that are 77requested. Contributors and maintainers alike should address these comments, if 78any, and then the PR is ready for merge. Wasmtime uses a [merge queue] to ensure 79that all tests pass before pushing to `main`. Note that the [merge queue] will 80run more tests than is run on PRs by default. 81 82Contributors should expect Wasmtime maintainers to add the PR to the merge queue 83for them. If a PR hasn't been added, and it's approved with all comments 84addressed, feel free to leave a comment to notify maintainers that it's ready. 85Maintainers can add their own PRs to the merge queue. When approving a PR 86maintainers may also add the PR to the merge queue at that time if there are no 87remaining comments. 88 89Note that if CI is failing on a PR then GitHub will automatically block adding a 90PR to the [merge queue]. PR authors will need to resolve PR CI before it can be 91added to the merge queue. If the merge queue CI fails then the PR will be 92removed from the merge queue and GitHub will leave a marker on the timeline and 93send a notification to the PR author. PR authors are expected to review CI logs 94and fix any failures in the PR itself. When ready maintainers can re-add their 95own PR for minor fixes and contributors can leave a comment saying that the PR 96is ready to be re-added to the queue. 97 98To run full CI on the PR before the merge queue, include the string 99`prtest:full` in any commit in the PR. That can help debug CI failures without 100going through the merge queue if necessary. 101 102[issues]: https://guides.github.com/features/issues/ 103[pull requests]: https://help.github.com/articles/about-pull-requests/ 104[issue keywords]: https://help.github.com/articles/closing-issues-using-keywords/ 105[newissue]: https://github.com/bytecodealliance/wasmtime/issues/new 106[meetings]: https://github.com/bytecodealliance/meetings/tree/main/wasmtime 107[merge queue]: https://github.com/bytecodealliance/wasmtime/queue/main 108