Firmware/opensbi
8
0
Fork 0
forked from Mirrors/opensbi
Code Pull Requests Activity

docs: Typo fixes.

Browse Source 
Signed-off-by: Atish Patra <atish.patra@wdc.com>
This commit is contained in:
Atish Patra
2019-01-21 00:01:23 -08:00
committed by Anup Patel
parent d9c06d0a8d
commit f293d21863
4 changed files with 22 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/contributing.md
View File

@@ -1,13 +1,13 @@
OpenSBI Contributing Guidelines
===============================
All contributions to OpenSBI should be sent as GitHub Pull Requests (PRs) to the main repo avaliable at: https://github.com/riscv/opensbi
All contributions to OpenSBI should be sent as GitHub Pull Requests (PRs) to the main repository avaliable at: https://github.com/riscv/opensbi
As well as that all work must follow the following rules:
1. We follow the [Linux coding style](https://www.kernel.org/doc/html/v4.10/process/coding-style.html). This means that ALL patches must include the Signed-off-by line.
2. Commit subject must have atleast one ":" prefix. Common ones are "lib:", "platform:", "firmware:", "docs:" and "top:".
3. Maintainer should prefer "Rebase and Merge" when using GitHub to merge pull requests. Avoid create extra merge commits.
4. Maintainer should avoid creating branches directly in main riscv/opensbi repo. Instead prefer fork of GitHub riscv/opensbi repo and create branches in your own fork for pull requests.
2. Commit subject must have at least one ":" prefix. Common ones are "lib:", "platform:", "firmware:", "docs:" and "top:".
3. Maintainer should use "Rebase and Merge" when using GitHub to merge pull requests to avoid unnecessary merge commits.
4. Maintainer should avoid creating branches directly in main riscv/opensbi repository. Instead prefer fork of GitHub riscv/opensbi repository and create branches in your own fork for pull requests.
5. Maintainer cannot merge his own pull requests on GitHub.
6. A pull request must get atleast one review from relevant maintainer.
7. A pull request must spend atleast 24 hours in review so that everyone gets a chance to review.
6. A pull request must get at least one review from relevant maintainer.
7. A pull request must spend at least 24 hours in review so that everyone gets a chance to review.