docs/devel/code-provenance.rst

1 .. _code-provenance:
9 The QEMU community **mandates** all contributors to certify provenance of
10 patch submissions they make to the project. To put it another way,
12 the project.
17    Signed-off-by: YOUR NAME <YOUR@EMAIL>
27   By making a contribution to this project, I certify that:
45   (d) I understand and agree that this project and the contribution
47       personal information I submit with it, including my sign-off) is
49       this project or the open source license(s) involved.
51 The name used with "Signed-off-by" does not need to be your legal name, nor
57 ``Signed-off-by`` lines, matches that of the git commit ``Author`` field.
63 nonetheless expected to add their own ``Signed-off-by`` to comply with the
70 this scenario, git commits will usually be expected to have a ``Signed-off-by``
73   * The non-primary author's contributions were so trivial that they can be
75     need not include a ``Signed-off-by``.
77     This case most commonly applies where QEMU reviewers give short snippets
79     their own ``Signed-off-by`` added unless their code suggestion was
80     unusually large, but it is common to add ``Suggested-by`` as a credit
81     for non-trivial code.
86     It can be said that in this case a ``Signed-off-by`` is indicating that
89     ``Signed-off-by`` for each contributor, as in some countries employees are
93 When multiple ``Signed-off-by`` tags are present, they should be strictly kept
99 While the ``Signed-off-by`` tag is mandatory, there are a number of other tags
100 that are commonly used during QEMU development:
102  * **``Reviewed-by``**: when a QEMU community member reviews a patch on the
104    email reply containing a ``Reviewed-by`` tag. Subsystem maintainers who
106    ``Signed-off-by`` to the same commit.
108  * **``Acked-by``**: when a QEMU subsystem maintainer approves a patch that
111    ``Acked-by`` tag. Where a patch touches multiple subsystems, ``Acked-by``
114    a ``Reviewed-by`` tag.
116  * **``Tested-by``**: when a QEMU community member has functionally tested the
118    containing a ``Tested-by`` tag.
120  * **``Reported-by``**: when a QEMU community member reports a problem via the
122    it is good practice to credit them by including a ``Reported-by`` tag on
127  * **``Suggested-by``**: when a reviewer or other 3rd party makes non-trivial
129    by including a ``Suggested-by`` tag.
136 suitable ``Signed-off-by`` tags.
139 **must** also then add their own ``Signed-off-by`` to indicate that they have
141 ``Reviewed-by`` tags the subsystem maintainer may wish to include.
145 commit message, just prior to the maintainer's ``Signed-off-by``::
147     Signed-off-by: Cory Contributor <cory.contributor@example.com>
149     Signed-off-by: Mary Maintainer <mary.maintainer@mycorp.test>
152 Tools for adding ``Signed-off-by``
155 There are a variety of ways tools can support adding ``Signed-off-by`` tags
162 When creating, or amending, a commit the ``-s`` flag to ``git commit`` will
165 If preparing patches using the ``git format-patch`` tool, the ``-s`` flag can
169   git rebase master -x 'git commit --amend --no-edit -s'
178   (define-abbrev-table 'global-abbrev-table
180       ("8rev" "Reviewed-by: YOUR NAME <your@email.addr>" nil 1)
181       ("8ack" "Acked-by: YOUR NAME <your@email.addr>" nil 1)
182       ("8test" "Tested-by: YOUR NAME <your@email.addr>" nil 1)
183       ("8sob" "Signed-off-by: YOUR NAME <your@email.addr>" nil 1)
194   iabbrev 8rev Reviewed-by: YOUR NAME <your@email.addr>
195   iabbrev 8ack Acked-by: YOUR NAME <your@email.addr>
196   iabbrev 8test Tested-by: YOUR NAME <your@email.addr>
197   iabbrev 8sob Signed-off-by: YOUR NAME <your@email.addr>
202 Re-starting abandoned work
205 For a variety of reasons there are some patches that get submitted to QEMU but
207 continue working from the abandoned patch and re-submit it with extra changes.
212    original ``Signed-off-by``
216    ``Signed-off-by`` in the patch in addition to the orignal author's
219    ``Signed-off-by``::
221     Signed-off-by: Some Person <some.person@example.com>
223     Signed-off-by: New Person <new.person@mycorp.test>
225 In complicated cases, or if otherwise unsure, ask for advice on the project
235 Files in patches contributed to QEMU are generally expected to be provided
238 appropriate to contribute to QEMU.
243 to expect those building QEMU to run the code generation or compilation
244 process. A non-exhaustive list of examples is:
251  * Firmware: QEMU includes pre-compiled binary ROMs for a variety of guest
257    with the libvirt-ci git submodule link. The generated dockerfiles are
261  * eBPF: QEMU includes some generated eBPF machine code, since the required
264    provided. This is a time-limited exception until the eBPF toolchain is
293   **Current QEMU project policy is to DECLINE any contributions which are
297 The increasing prevalence of AI-assisted software development results in a
299 QEMU.  Of particular concern is content generated by `Large Language Models
302 The QEMU community requires that contributors certify their patch submissions
307 copyright and license status of content they are contributing to QEMU. With AI
309 ill-defined with no generally accepted, settled legal foundation.
315 with QEMU's licensing requirements.
318 content generators commonly available today is unclear.  The QEMU project is
319 not willing or able to accept the legal risks of non-compliance.
321 The QEMU project thus requires that contributors refrain from using AI content
322 generators on patches intended to be submitted to the project, and will
335 evaluated by the QEMU project on a case by case basis. To be granted an
338 code, to the satisfaction of the project maintainers.