User Tools

Site Tools


en:developers:documentation:submittingpatches

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
en:developers:documentation:submittingpatches [2017/08/03 04:47]
Kalle Valo Add "Commit log does not answer "Why?""
en:developers:documentation:submittingpatches [2018/11/16 08:37]
Kalle Valo Add a section about tree labels
Line 35: Line 35:
 ===== Checking state of patches from patchwork ===== ===== Checking state of patches from patchwork =====
  
-All wireless patches are tracked in [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/​|linux-wireless patchwork project]] ​(only exception being ath10k which has its own [[https://​patchwork.kernel.org/​project/​ath10k/​list/?​state=*|ath10k patchwork project]]). From patchwork you can check the state of the patch and to whom it is assigned. Here's a quick link to see all the patches, no matter what's the state:+All wireless patches are tracked in [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/​|linux-wireless patchwork project]]. From patchwork you can check the state of the patch and to whom it is assigned. Here's a quick link to see all the patches, no matter what's the state:
  
 [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/?​state=*]] [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/?​state=*]]
  
-Always avoid contacting maintainers directly, they get way too much email already. Instead use the link above to find your patch and see the status. Only in last resort contact the maintainers,​ and do that by replying to your own patch and ask for status.+Always avoid contacting maintainers directly, they get way too much email already. Instead use the link above to find your patch and see the status. Only in last resort contact the maintainers,​ and do that by replying to your own patch and ask for status. ​Do not top post!
  
 Different patchwork states and their meanings: Different patchwork states and their meanings:
Line 93: Line 93:
  
 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.
 +
 +===== Tree labels =====
 +
 +Labeling patches with what tree the patch should go to helps maintainers to prioritise and sort patches and avoids unnecessary emails, which saves everyone time and speeds up patch review. Here are some tips how to label wireless patches.
 +
 +If you want to target your patch to a specific release (for example that the patch should go -rc release not -next) you can inform the maintainer by adding the release number inside the PATCH brackets:
 + 
 +<​code>​[PATCH 4.20] subsystem: fix foo</​code>​
 +
 +If you want to make it clear to the maintainer that the patch should NOT go to -rc release but to -next instead you can add "​-next"​ to PATCH brackets:
 +
 +<​code>​[PATCH -next] subsystem: fix foo</​code>​
 +
 +Alternatively you can specify the exact tree you are targetting by adding the name of the git tree inside PATCH brackets:
 +
 +<​code>​[PATCH mac80211] mac80211: fix foo
 +[PATCH mac80211-next] mac80211: implement very-cool-feature
 +[PATCH wireless-drivers] ath10k: fix foo
 +[PATCH wireless-drivers-next] ath10k: implement awesome-feature
 +</​code>​
 +
  
 ===== Sending large patches or multiple patches ===== ===== Sending large patches or multiple patches =====
Line 111: Line 132:
 ===== Format of patches ===== ===== Format of patches =====
  
-We prefer patches to be inline-text at the end of the body of the e-mail. ​You can use git-diff or the like to generate ​the patch. Additionally note that we prefer to apply patches with -p1. A header as follows is then acceptable: ​+We prefer patches to be inline-text at the end of the body of the e-mail. ​It's strongly recommended to use git-format-patch and git-send-email tools to submit patches as they use the correct format automatically. Additionally note that we prefer to apply patches with git-am (using the -p1 diff format). A header as follows is then acceptable: ​
  
  
Line 232: Line 253:
 ==== Changelog missing ==== ==== Changelog missing ====
  
-When sending a new version of a patch or patchset you should **always** add a changelog so that maintainer can easily what has changed.+When sending a new version of a patch or patchset you should **always** add a changelog so that maintainer can easily ​see what has changed.
  
 If you have just one patch you can add the changelog after the ''​%%---%%''​ (three dashes) line. If you have just one patch you can add the changelog after the ''​%%---%%''​ (three dashes) line.
  
-If you have multiples patches (called a patchset) add the changelog to the cover letter. You can create the cover letter with switch ''​--cover-letter'':​+If you have multiples patches (called a patchset) add the changelog to the cover letter. You can create the cover letter with the switch ''​--cover-letter'':​
  
   git format-patch --subject-prefix="​PATCH v2" --cover-letter   git format-patch --subject-prefix="​PATCH v2" --cover-letter
Line 321: Line 342:
 The commit log needs to tell why you wrote the patch. If you fixed a bug give a short summary of the bug (can be a long one as well, of course) from user's point of view, and if there'​s a publically available bug report include a link to that. If you are fixing a warning from a compiler or a static checker add the warning from tool. Or if it's just code cleanup or fixing a theoretical issue, and does not have practical user visible changes, mention that also. The commit log needs to tell why you wrote the patch. If you fixed a bug give a short summary of the bug (can be a long one as well, of course) from user's point of view, and if there'​s a publically available bug report include a link to that. If you are fixing a warning from a compiler or a static checker add the warning from tool. Or if it's just code cleanup or fixing a theoretical issue, and does not have practical user visible changes, mention that also.
  
-===== More patch work references =====+==== Do not top post and edit your quotes ​==== 
 + 
 +Top posting makes following email threads hard to follow and also it makes use of patchwork more difficult, which gets the maintainers grumpy as you are making their work more difficult. So do not top post and instead edit your quotes properly. 
 + 
 +<​code>​A:​ Because it messes up the order in which people normally read text. 
 +Q: Why is top-posting such a bad thing? 
 +A: Top-posting. 
 +Q: What is the most annoying thing in e-mail? 
 + 
 +A: No. 
 +Q: Should I include quotations after my reply? 
 +</​code>​ 
 + 
 +More info: http://​www.idallen.com/​topposting.html 
 + 
 +==== Use RFC or RFT for patches not ready ==== 
 + 
 +If the patches are not yet ready to be applied by the maintainer mark them as RFC (Request For Comments) or RFC (Request For Test), this way the maintainer can easily see that the patch should not be applied yet. This saves a lot of maintainer'​s time. 
 + 
 + 
 +===== More references =====
  
 Here is a list of links to help you write better patches ​ Here is a list of links to help you write better patches ​
Line 329: Line 370:
   * [[http://​linux.yyz.us/​patch-format.html|http://​linux.yyz.us/​patch-format.html]] ​   * [[http://​linux.yyz.us/​patch-format.html|http://​linux.yyz.us/​patch-format.html]] ​
   * [[https://​www.ozlabs.org/​~akpm/​stuff/​tpp.txt|Andrew Morton'​s ''​The perfect patch''​]] ​   * [[https://​www.ozlabs.org/​~akpm/​stuff/​tpp.txt|Andrew Morton'​s ''​The perfect patch''​]] ​
 +  * [[http://​lkml.kernel.org/​r/​20171026223701.GA25649@bhelgaas-glaptop.roam.corp.google.com|Make Bjorn'​s life easier (and grease the path of your patch)]]
en/developers/documentation/submittingpatches.txt · Last modified: 2019/06/23 09:14 by Thomas Nagy