It's been more than six months since we adopted GLib and we've been pretty aggressive at replacing our homegrown APIs with more standard ones, so by now most of the symbols mentioned in this document haven't been around for quite a long time already. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2.6 KiB
Contributing
These are the basics steps you need to follow to contribute to libvirt.
Repositories and external resources
The official upstream repository is kept in git (https://libvirt.org/git/libvirt.git
) and is browsable along with other libvirt-related repositories (e.g. libvirt-python) online.
Patches to translations are maintained via the zanata project. If you want to fix a translation in a .po file, join the appropriate language team. The libvirt release process automatically pulls the latest version of each translation file from zanata.
Preparing patches
Make sure your patches apply against libvirt git. Developers only follow git and don't care much about released versions.
Run the automated tests on your code before submitting any changes. That is:
$ make check
$ make syntax-check
These tests help making sure that your changes don't introduce regressions in libvirt, as well as validating that any new code follows the project's coding style.
If you're going to submit multiple patches, the automated tests must pass after each patch, not just after the last one.
Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program, and don't forget to update the release notes if your changes are significant and user-visible.
Submitting patches
Libvirt uses a mailing list based development workflow.
While preparing your patches for submissions, make sure you follow the best practices and, once you're satisfied with the result, go ahead and submit your patches.
Developer Certificate of Origin
Contributors to libvirt projects must assert that they are in compliance with the Developer Certificate of Origin 1.1. This is achieved by adding a "Signed-off-by" line containing the contributor's name and e-mail to every commit message. The presence of this line attests that the contributor has read the above lined DCO and agrees with its statements.
Further reading
This page only covers the very basics, so it's recommended that you also take a look at the following documents: