We hope to build a vibrant community-driven effort to carry SVMP into the future. We welcome your participation in any way, big or small, be it reporting bugs, sharing ideas for interesting new features, or contributing code. SVMP today provides a valuable capability, but more importantly it is a foundation for fantastic new creations of tomorrow.
We don’t have a central internet facing issue tracker at this time. Until such time that we do, please use the mailing list and Github bug trackers.
Send a note to the developer mailing list and create a new issue in the most appropriate Github project tracker.
Be as specific as you can about the failure, the conditions under which it occured, how to reproduce it, and any error logs you can obtain from the time the failure occured. The more information you provide, the more likely we can quickly fix the problem.
Send suggestions for improvements or new features to the developer mailing list.
First, make sure to configure git with your real name and email address.
Please try to stick to the following format for patches as much as possible:
- First line containing a short, but clear description of the main purpose of the patch. ~60 characters max.
- Blank second line
- Body containing a long form description of everything done in the patch. For merge commits, include the list of commits with their tag lines that are pulled in by the merge. Wrap your text and keep lines under 80 characters.
- Signed-off-by line
- Change-id line if pushing to Gerrit
Don’t do them. We prefer a straight-line commit history for the SVMP repositories wherever possible as this is the preference of the Gerrit code review tool that manages all the git repositories. Please rebase your patches into a straight-line, fast-forwardable patch series before pushing.
If you find yourself needing to do a merge commit and have a really good reason for doing so, send a message to the developer mailing list explaining what you are trying to do and ask for assistance on how to proceed.
Gerrit, repo, and the Change-id line
All code contributions go through a Gerrit code review server before being merged to the mainline release. To track different versions of a proposed patch, Gerrit uses a “Change-id” line in the commit message.
When working with the AOSP-based virtual machine code, the `repo` tool will handle this automatically. Most of the upstream AOSP documentation for working with repo and how to submit patches applies equally to SVMP
For the other SVMP components (clients, server, etc.), you will need to add these lines yourself. Consult the Gerrit documentation for more information, including how to create a local git commit hook to automatically add the Change-id lines for you.
You may also find the `git-review` tool useful when working with repositories managed by Gerrit. It too will automatically handle
License and Copyright
SVMP is distributed primarily under the Apache License, Version 2.0.
We do not ask for a copyright assignment for code contributions. We do however ask that you provide patches in a way that is compatible with inclusion into an Apache licensed project. When modifying existing files, you may choose to add a brief note to the header comments with your name, the date, and what you modified to make changes easier to track. If adding new files, place an appropriate copyright and license notice in the file header. Files without an explicit open source license have to be considered “All Rights Reserved” and cannot be included.
Patches without a Signed-off-by line cannot be considered for inclusion, and will in fact be rejected by the Gerrit code review system.
To assure the chain of trust, for received patches the SVMP project uses the signed-off-by process as used by the Linux kernel.
This means that each submitted patch must include a “Signed-off-by” line in the commit message with your real name and email address (no pseudonyms or anonymous contributions). Including this line indicates you certify that you have the right to contribute the patch under the license specified in the contributed code and adhere to the following:
"Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved."
Some external references on this process as it is used in other projects:
- Linux Kernel SubmittingPatches doc, ‘Sign your work’ Section