mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 04:41:20 +00:00

Tim Small 7160215146 docs: Advise running CI tests prior to submission

In the preparing patches section, note that it is possible to run CI
tests via gitlab prior to submitting patches.

Signed-off-by: Tim Small <tim@seoss.co.uk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>

2023-07-14 15:19:24 +02:00

3.5 KiB

Raw Blame History

Contributing

These are the basics steps you need to follow to contribute to libvirt software development.

Repositories and external resources

The official upstream repository is kept in git (https://gitlab.com/libvirt/libvirt) and is browsable along with other libvirt-related repositories (e.g. libvirt-python) online.

Patches to translations are maintained via the Fedora Weblate service. If you want to contribute to translations of libvirt, join the appropriate language team in Weblate. Translation updates to libvirt will be merged during the feature freeze window.

Working with the code

In general you should base your work upon the git master branch.

The "Git checkout" section of the libvirt installation instructions give an overview of the compilation process.

Optionally, Clangd with libvirt can be used to navigate the code base etc. within most code editors (and IDEs).

Preparing patches

Make sure your patches apply against the libvirt git master branch. The backporting of changes to existing releases is typically carried out by downstream users at their discretion after code is merged into the upstream git.

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

$ ninja test

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.

To test across a variety of build platforms prior to submitting your changes, you may create your own fork of the project on gitlab. This will give you access to (a subset of) libvirt's continuous integration test suite.

Please note that you should still follow the instructions below, rather than following gitlab's prompts to open a "merge request".

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.

3.5 KiB Raw Blame History