1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
|
============
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>`__
|
