External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-12 12:55:46 +00:00
Code Issues Packages Projects Releases Wiki Activity
435eff1447
libvirt/docs/hacking.rst
Andrea Bolognani 435eff1447 docs: Add best-practices.rst 
These guidelines should already be familiar to people who have
contributed to other open source projects, so it doesn't make much
sense for them to be so prominent. Move them to a separate page.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2020-04-08 09:32:44 +02:00

2.0 KiB
Raw Blame History

Contributor guidelines

General tips for contributing patches

  1. 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.

  2. 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.

  3. 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.

  4. Make sure your patches apply against libvirt GIT. Developers only follow GIT and don't care much about released versions.

  5. Run the automated tests on your code before submitting any changes. That is:

    make check
make syntax-check

  6. Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program.

  7. Don't forget to update the release notes by changing docs/news.xml if your changes are significant. All user-visible changes, such as adding new XML elements or fixing all but the most obscure bugs, must be (briefly) described in a release notes entry; changes that are only relevant to other libvirt developers, such as code refactoring, don't belong in the release notes. Note that docs/news.xml should be updated in its own commit not to get in the way of backports.