User Tools

Site Tools


en:users:drivers:ath10k: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:users:drivers:ath10k:submittingpatches [2019/02/15 11:59]
Kalle Valo Add links to submitting patches and how to write git commit messages
en:users:drivers:ath10k:submittingpatches [2020/06/09 12:22]
Kalle Valo Add a section about answering to why
Line 10: Line 10:
 Preferably use [[en/​users/​drivers/​ath10k/​sources|ath.git master branch]] as the baseline for patches. Other trees can be used as well, but then the chances of conflicts are higher. Preferably use [[en/​users/​drivers/​ath10k/​sources|ath.git master branch]] as the baseline for patches. Other trees can be used as well, but then the chances of conflicts are higher.
  
-You can follow the state of ath10k patch review from patchwork:+It's important that linux-wireless is CCed on the patches, otherwise it won't be in patchwork and the maintainer won't see it. You can follow the state of ath10k patch review from patchwork:
  
 [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/?​state=*&​q=ath10k]] [[https://​patchwork.kernel.org/​project/​linux-wireless/​list/?​state=*&​q=ath10k]]
Line 19: Line 19:
         * [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html|Linux kernel submitting patches]]         * [[https://​www.kernel.org/​doc/​html/​latest/​process/​submitting-patches.html|Linux kernel submitting patches]]
         * [[https://​medium.com/​@steveamaza/​how-to-write-a-proper-git-commit-message-e028865e5791|How to write proper git commit messages]]         * [[https://​medium.com/​@steveamaza/​how-to-write-a-proper-git-commit-message-e028865e5791|How to write proper git commit messages]]
 +        * [[https://​lkml.kernel.org/​r/​20150314075357.GA8319@gmail.com|Ingo Molnar'​s points about commit logs]]
  
 ==== Guidelines ==== ==== Guidelines ====
Line 29: Line 30:
   * [[https://​www.kernel.org/​pub/​software/​scm/​git/​docs/​git-send-email.html|git send-email]] SHOULD be used to submit the patch to avoid any formatting issues.   * [[https://​www.kernel.org/​pub/​software/​scm/​git/​docs/​git-send-email.html|git send-email]] SHOULD be used to submit the patch to avoid any formatting issues.
   * Patchsets SHOULD contain no more than 12 patches and include a cover letter. ​   * Patchsets SHOULD contain no more than 12 patches and include a cover letter. ​
-  * Commit log MUST answer the question "​Why?"​:  +  * Commit log MUST [[#​answer_to_why|answer the question "​Why?"​]]
-    * Describe the motivation behind the bug.  +  The commit log MUST not be empty.
-    How does it change the functionality from user's point of view?  +
-    * Does it fix a bug? If it does, please describe the bug (doesn'​t necessarily need to be long). Also if there'​s a public bug report add a link to the bug report or email describing the issue.  +
-    * If a problem has been found during code review and doesn'​t fix a known issue, mention that in the commit log this is a theoretical fix. +
-    * This also implies that the commit log MUST not be empty.  +
-    * Ingo Molnar has written [[https://​lkml.kernel.org/​r/​20150314075357.GA8319@gmail.com|a nice description]] about what maintainers are looking from a commit log.+
   * Commit log MUST document the affected hardware versions, bus type and firmware version(s) tested, examples:   * Commit log MUST document the affected hardware versions, bus type and firmware version(s) tested, examples:
     * QCA988X PCI 10.2.4-1.0-00037     * QCA988X PCI 10.2.4-1.0-00037
Line 46: Line 42:
  
 The terminology is from [[http://​www.ietf.org/​rfc/​rfc2119.txt|http://​www.ietf.org/​rfc/​rfc2119.txt]] ​ The terminology is from [[http://​www.ietf.org/​rfc/​rfc2119.txt|http://​www.ietf.org/​rfc/​rfc2119.txt]] ​
 +
 +
 +==== Answer to "​Why?"​ ====
 +
 +The commit log needs to describe the motivation behind the bug, in other words provide the background information why the patch is needed and why is it needed the way it is.
 +
 +  * How does it change the functionality from user's point of view? 
 +  * Does it fix a bug? If it does, please describe the bug (doesn'​t necessarily need to be long). Also if there'​s a public bug report add a link to the bug report or email describing the issue. ​
 +  * If a problem has been found during code review and doesn'​t fix a known issue, mention that in the commit log this is a theoretical fix.
 +
 +Ingo Molnar has written [[https://​lkml.kernel.org/​r/​20150314075357.GA8319@gmail.com|a nice description]] about what maintainers are looking from a commit log, read that to understand more about commit logs.
  
 ==== Patch flow ==== ==== Patch flow ====
en/users/drivers/ath10k/submittingpatches.txt · Last modified: 2020/08/26 14:40 by Kalle Valo