1# Contributing to Cloud Hypervisor 2 3Cloud Hypervisor is an open source project licensed under the [Apache v2 License](https://opensource.org/licenses/Apache-2.0) and the [BSD 3 Clause](https://opensource.org/licenses/BSD-3-Clause) license. 4 5## Coding Style 6 7We follow the [Rust Style](https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/guide.md) 8convention and enforce it through the Continuous Integration (CI) process calling into `rustfmt` 9for each submitted Pull Request (PR). 10 11## Certificate of Origin 12 13In order to get a clear contribution chain of trust we use the [signed-off-by language](https://01.org/community/signed-process) 14used by the Linux kernel project. 15 16## Patch format 17 18Beside the signed-off-by footer, we expect each patch to comply with the following format: 19 20``` 21<component>: Change summary 22 23More detailed explanation of your changes: Why and how. 24Wrap it to 72 characters. 25See http://chris.beams.io/posts/git-commit/ 26for some more good pieces of advice. 27 28Signed-off-by: <contributor@foo.com> 29``` 30 31For example: 32 33``` 34vm-virtio: Reset underlying device on driver request 35 36If the driver triggers a reset by writing zero into the status register 37then reset the underlying device if supported. A device reset also 38requires resetting various aspects of the queue. 39 40In order to be able to do a subsequent reactivate it is required to 41reclaim certain resources (interrupt and queue EventFDs.) If a device 42reset is requested by the driver but the underlying device does not 43support it then generate an error as the driver would not be able to 44configure it anyway. 45 46Signed-off-by: Rob Bradford <robert.bradford@intel.com> 47``` 48 49## Pull requests 50 51Cloud Hypervisor uses the “fork-and-pull” development model. Follow these steps if 52you want to merge your changes to `cloud-hypervisor`: 53 541. Fork the [cloud-hypervisor](https://github.com/cloud-hypervisor/cloud-hypervisor) project 55 into your github organization. 562. Within your fork, create a branch for your contribution. 573. [Create a pull request](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) 58 against the main branch of the Cloud Hypervisor repository. 594. Add reviewers to your pull request and then work with your reviewers to address 60 any comments and obtain minimum of 2 [maintainers](MAINTAINERS.md) approvals. 61 To update your pull request amend existing commits whenever applicable and 62 then push the new changes to your pull request branch. 635. Once the pull request is approved, one of the maintainers will merge it. 64 65## Issue tracking 66 67If you have a problem, please let us know. We recommend using 68[github issues](https://github.com/cloud-hypervisor/cloud-hypervisor/issues/new) for formally 69reporting and documenting them. 70 71To quickly and informally bring something up to us, you can also reach out on [Slack](https://cloud-hypervisor.slack.com). 72 73## Closing issues 74 75You can either close issues manually by adding the fixing commit SHA1 to the issue 76comments or by adding the `Fixes` keyword to your commit message: 77 78``` 79serial: Set terminal in raw mode 80 81In order to have proper output from the serial, we need to setup the 82terminal in raw mode. When the VM is shutting down, it is also the 83VMM responsibility to set the terminal back into canonical mode if we 84don't want to get any weird behavior from the shell. 85 86Fixes #88 87 88Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> 89``` 90 91Then, after the corresponding PR is merged, Github will automatically close that issue when parsing the 92[commit message](https://help.github.com/articles/closing-issues-via-commit-messages/). 93