en:developers:documentation:submittingpatches
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | Next revision Both sides next revision | ||
|
en:developers:documentation:submittingpatches [2020/10/12 13:19] Kalle Valo [New driver] overview of the driver |
en:developers:documentation:submittingpatches [2021/02/12 08:22] Johannes Berg |
||
|---|---|---|---|
| Line 57: | Line 57: | ||
| ===== Subject ===== | ===== Subject ===== | ||
| - | If what you are sending is a patch you can use a subject as follows: | + | If what you are sending is a patch you should use a subject as follows: |
| Line 81: | Line 81: | ||
| If your patch is just a proposal you can mark the patch as RFC in the subject: | If your patch is just a proposal you can mark the patch as RFC in the subject: | ||
| - | <code>[RFC] subsystem: a new way to do foo</code> | + | <code>[RFC] subsystem: add a new way to do foo</code> |
| If you need to make changes to the patch add a version number inside the brackets: | If you need to make changes to the patch add a version number inside the brackets: | ||
| Line 94: | Line 94: | ||
| If a patch in a bigger patchset changes resubmit the whole patchset, even the patches which have not changes. The maintainers look at patchsets as a complete unit, usually they do not want to take patches individually from a patchset. | If a patch in a bigger patchset changes resubmit the whole patchset, even the patches which have not changes. The maintainers look at patchsets as a complete unit, usually they do not want to take patches individually from a patchset. | ||
| + | |||
| + | Subject lines, like commit messages (see below) should be written in imperative voice ("fix foo and optimize bar"), not in any other way such as past tense ("fixed foo and optimized bar"). | ||
| + | |||
| + | ===== Commit Messages ===== | ||
| + | |||
| + | Please write commit messages, like mentioned for the subject above, in imperative voice. | ||
| + | |||
| + | Commit messages should describe | ||
| + | * why a change was made, | ||
| + | * how it achieves its stated goal, and, | ||
| + | * if applicable, other considerations such as | ||
| + | * alternatives that were considered, | ||
| + | * implications on other code, | ||
| + | * possible security implications, | ||
| + | * etc. | ||
| + | |||
| + | If you find yourself listing out a number of changes in the commit message as a bulleted list or similar, consider splitting up the patch into discrete changes that each do one thing. Similarly, if one of the additional considerations is refactoring, try to shift that into a separate patch. | ||
| ===== Tree labels ===== | ===== Tree labels ===== | ||
en/developers/documentation/submittingpatches.txt ยท Last modified: 2024/02/01 20:12 by Jeff Johnson
Page Tools
