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