69e3c6cf42
File name needs to be `CONTRIBUTING` for GitHub to pick it up as a valid file for contributor guidelines. See https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors#adding-a-contributing-file Signed-off-by: Danilo Del Busso <danilo.delbusso@cloud.com>
1.8 KiB
How to submit changes
Please try to follow the guidelines below. They will make things easier on the maintainers. Not all of these guidelines matter for every trivial change so apply some common sense.
If you are unsure about something written here, ask on the mailing list xs-devel@lists.xenserver.org.
-
Before starting a big project, discuss it on the list first :-)
-
Always test your changes, however small, by both targetted manual testing and by running the unit tests.
-
When adding new functionality, include test cases for any
- important; or
- difficult to manually test; or
- easy to break new code.
-
All submissions must be made under the terms of the "Developer's Certificate of Origin" (DCO) and should include a Signed-off-by: line.
-
Make your patch(es) available by creating one or more github pull requests. Each pull request should be separately reviewable and mergable. Only patches which must be committed together should be in the same pull request.
-
Each patch should include a descriptive commit comment that helps understand why the patch is necessary and why it works. This will be used both for initial review and for new people to understand how the code works later.
-
For bonus points, ensure the project still builds in between every patch in a set: this helps hunt down future regressions with 'bisect'.
-
Make sure you have the right to submit any changes you make. If you do changes at work you may find your employer owns the patches instead of you.
For a list of maintainers, please see MAINTAINERS file.