mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-11-11 12:24:25 +03:00
1686db62ed
This policy is a copy of what QEMU project is using [1] as there is no reason to use different policy, only modification is changing the project name and link to DCO. [1] <https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-content-generators> Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
156 lines
6.3 KiB
ReStructuredText
156 lines
6.3 KiB
ReStructuredText
============
|
|
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 <https://gitlab.com/libvirt>`__.
|
|
|
|
Patches to translations are maintained via the `Fedora Weblate
|
|
service <https://translate.fedoraproject.org/projects/libvirt/libvirt>`__.
|
|
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 <compiling.html#git-checkout>`__
|
|
of the libvirt installation instructions give an overview of the
|
|
compilation process.
|
|
|
|
Optionally, `Clangd with libvirt <clangd.html>`__ 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 <coding-style.html>`__.
|
|
|
|
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 <news.html>`__ 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 <ci.html>`__ 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 <best-practices.html>`__ and, once
|
|
you're satisfied with the result, go ahead and
|
|
`submit your patches <submitting-patches.html>`__.
|
|
|
|
Developer Certificate of Origin
|
|
===============================
|
|
|
|
Contributors to libvirt projects **must** assert that they are
|
|
in compliance with the `Developer Certificate of Origin
|
|
1.1 <https://developercertificate.org/>`__. This is achieved by
|
|
adding a "Signed-off-by" line containing the contributor's name
|
|
and e-mail to every commit message. The name should be the identity
|
|
the contributor has chosen to be known as in the context of the
|
|
community. It does not need to be a legal name, nor match any
|
|
formal ID documents, but should not be anonymous, nor misrepresent
|
|
who you are. The presence of this line attests that the contributor
|
|
has read the above linked DCO and agrees with its statements.
|
|
|
|
Use of AI content generators
|
|
============================
|
|
|
|
TL;DR:
|
|
|
|
**Current libvirt project policy is to DECLINE any contributions which are
|
|
believed to include or derive from AI generated content. This includes
|
|
ChatGPT, Claude, Copilot, Llama and similar tools.**
|
|
|
|
The increasing prevalence of AI-assisted software development results in a
|
|
number of difficult legal questions and risks for software projects, including
|
|
libvirt. Of particular concern is content generated by `Large Language Models
|
|
<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
|
|
|
|
The libvirt community requires that contributors certify their patch submissions
|
|
are made in accordance with the rules of the `Developer Certificate of
|
|
Origin`_.
|
|
|
|
To satisfy the DCO, the patch contributor has to fully understand the
|
|
copyright and license status of content they are contributing to libvirt. With
|
|
AI content generators, the copyright and license status of the output is
|
|
ill-defined with no generally accepted, settled legal foundation.
|
|
|
|
Where the training material is known, it is common for it to include large
|
|
volumes of material under restrictive licensing/copyright terms. Even where
|
|
the training material is all known to be under open source licenses, it is
|
|
likely to be under a variety of terms, not all of which will be compatible
|
|
with libvirt's licensing requirements.
|
|
|
|
How contributors could comply with DCO terms (b) or (c) for the output of AI
|
|
content generators commonly available today is unclear. The libvirt project is
|
|
not willing or able to accept the legal risks of non-compliance.
|
|
|
|
The libvirt project thus requires that contributors refrain from using AI
|
|
content generators on patches intended to be submitted to the project, and
|
|
will decline any contribution if use of AI is either known or suspected.
|
|
|
|
This policy does not apply to other uses of AI, such as researching APIs or
|
|
algorithms, static analysis, or debugging, provided their output is not to be
|
|
included in contributions.
|
|
|
|
Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
|
|
ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
|
|
generation agents which are built on top of such tools.
|
|
|
|
This policy may evolve as AI tools mature and the legal situation is
|
|
clarified. In the meanwhile, requests for exceptions to this policy will be
|
|
evaluated by the libvirt project on a case by case basis. To be granted an
|
|
exception, a contributor will need to demonstrate clarity of the license and
|
|
copyright status for the tool's output in relation to its training model and
|
|
code, to the satisfaction of the project maintainers.
|
|
|
|
Further reading
|
|
===============
|
|
|
|
This page only covers the very basics, so it's recommended that
|
|
you also take a look at the following documents:
|
|
|
|
- `Programming languages <programming-languages.html>`__
|
|
- `Advanced test suite usage <advanced-tests.html>`__
|
|
- `Adoption of GLib APIs <glib-adoption.html>`__
|
|
- `Committer guidelines <committer-guidelines.html>`__
|
|
- `Contributing to libvirt <contribute.html>`__
|