110 lines
4.4 KiB
ReStructuredText
110 lines
4.4 KiB
ReStructuredText
============================================
|
|
Kernel Guidelines for Tool-Generated Content
|
|
============================================
|
|
|
|
Purpose
|
|
=======
|
|
|
|
Kernel contributors have been using tooling to generate contributions
|
|
for a long time. These tools can increase the volume of contributions.
|
|
At the same time, reviewer and maintainer bandwidth is a scarce
|
|
resource. Understanding which portions of a contribution come from
|
|
humans versus tools is helpful to maintain those resources and keep
|
|
kernel development healthy.
|
|
|
|
The goal here is to clarify community expectations around tools. This
|
|
lets everyone become more productive while also maintaining high
|
|
degrees of trust between submitters and reviewers.
|
|
|
|
Out of Scope
|
|
============
|
|
|
|
These guidelines do not apply to tools that make trivial tweaks to
|
|
preexisting content. Nor do they pertain to tooling that helps with
|
|
menial tasks. Some examples:
|
|
|
|
- Spelling and grammar fix ups, like rephrasing to imperative voice
|
|
- Typing aids like identifier completion, common boilerplate or
|
|
trivial pattern completion
|
|
- Purely mechanical transformations like variable renaming
|
|
- Reformatting, like running Lindent, ``clang-format`` or
|
|
``rust-fmt``
|
|
|
|
Even whenever your tool use is out of scope, you should still always
|
|
consider if it would help reviewing your contribution if the reviewer
|
|
knows about the tool that you used.
|
|
|
|
In Scope
|
|
========
|
|
|
|
These guidelines apply when a meaningful amount of content in a kernel
|
|
contribution was not written by a person in the Signed-off-by chain,
|
|
but was instead created by a tool.
|
|
|
|
Detection of a problem and testing the fix for it is also part of the
|
|
development process; if a tool was used to find a problem addressed by
|
|
a change, that should be noted in the changelog. This not only gives
|
|
credit where it is due, it also helps fellow developers find out about
|
|
these tools.
|
|
|
|
Some examples:
|
|
- Any tool-suggested fix such as ``checkpatch.pl --fix``
|
|
- Coccinelle scripts
|
|
- A chatbot generated a new function in your patch to sort list entries.
|
|
- A .c file in the patch was originally generated by a coding
|
|
assistant but cleaned up by hand.
|
|
- The changelog was generated by handing the patch to a generative AI
|
|
tool and asking it to write the changelog.
|
|
- The changelog was translated from another language.
|
|
|
|
If in doubt, choose transparency and assume these guidelines apply to
|
|
your contribution.
|
|
|
|
Guidelines
|
|
==========
|
|
|
|
First, read the Developer's Certificate of Origin:
|
|
Documentation/process/submitting-patches.rst. Its rules are simple
|
|
and have been in place for a long time. They have covered many
|
|
tool-generated contributions. Ensure that you understand your entire
|
|
submission and are prepared to respond to review comments.
|
|
|
|
Second, when making a contribution, be transparent about the origin of
|
|
content in cover letters and changelogs. You can be more transparent
|
|
by adding information like this:
|
|
|
|
- What tools were used?
|
|
- The input to the tools you used, like the Coccinelle source script.
|
|
- If code was largely generated from a single or short set of
|
|
prompts, include those prompts. For longer sessions, include a
|
|
summary of the prompts and the nature of resulting assistance.
|
|
- Which portions of the content were affected by that tool?
|
|
- How is the submission tested and what tools were used to test the
|
|
fix?
|
|
|
|
As with all contributions, individual maintainers have discretion to
|
|
choose how they handle the contribution. For example, they might:
|
|
|
|
- Treat it just like any other contribution.
|
|
- Reject it outright.
|
|
- Treat the contribution specially, for example, asking for extra
|
|
testing, reviewing with extra scrutiny, or reviewing at a lower
|
|
priority than human-generated content.
|
|
- Ask for some other special steps, like asking the contributor to
|
|
elaborate on how the tool or model was trained.
|
|
- Ask the submitter to explain in more detail about the contribution
|
|
so that the maintainer can be assured that the submitter fully
|
|
understands how the code works.
|
|
- Suggest a better prompt instead of suggesting specific code changes.
|
|
|
|
If tools permit you to generate a contribution automatically, expect
|
|
additional scrutiny in proportion to how much of it was generated.
|
|
|
|
As with the output of any tooling, the result may be incorrect or
|
|
inappropriate. You are expected to understand and to be able to defend
|
|
everything you submit. If you are unable to do so, then do not submit
|
|
the resulting changes.
|
|
|
|
If you do so anyway, maintainers are entitled to reject your series
|
|
without detailed review.
|