| .. | .. |
|---|
| 9 | 9 | of conventions and procedures which are used in the posting of patches; |
|---|
| 10 | 10 | following them will make life much easier for everybody involved. This |
|---|
| 11 | 11 | document will attempt to cover these expectations in reasonable detail; |
|---|
| 12 | | -more information can also be found in the files process/submitting-patches.rst, |
|---|
| 13 | | -process/submitting-drivers.rst, and process/submit-checklist.rst in the kernel |
|---|
| 14 | | -documentation directory. |
|---|
| 12 | +more information can also be found in the files |
|---|
| 13 | +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`, |
|---|
| 14 | +:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>` |
|---|
| 15 | +and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`. |
|---|
| 15 | 16 | |
|---|
| 16 | 17 | |
|---|
| 17 | 18 | When to post |
|---|
| .. | .. |
|---|
| 198 | 199 | |
|---|
| 199 | 200 | The tags mentioned above are used to describe how various developers have |
|---|
| 200 | 201 | been associated with the development of this patch. They are described in |
|---|
| 201 | | -detail in the process/submitting-patches.rst document; what follows here is a |
|---|
| 202 | | -brief summary. Each of these lines has the format: |
|---|
| 202 | +detail in |
|---|
| 203 | +the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` |
|---|
| 204 | +document; what follows here is a brief summary. Each of these lines has |
|---|
| 205 | +the format: |
|---|
| 203 | 206 | |
|---|
| 204 | 207 | :: |
|---|
| 205 | 208 | |
|---|
| .. | .. |
|---|
| 210 | 213 | - Signed-off-by: this is a developer's certification that he or she has |
|---|
| 211 | 214 | the right to submit the patch for inclusion into the kernel. It is an |
|---|
| 212 | 215 | agreement to the Developer's Certificate of Origin, the full text of |
|---|
| 213 | | - which can be found in Documentation/process/submitting-patches.rst. Code |
|---|
| 214 | | - without a proper signoff cannot be merged into the mainline. |
|---|
| 216 | + which can be found in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` |
|---|
| 217 | + Code without a proper signoff cannot be merged into the mainline. |
|---|
| 215 | 218 | |
|---|
| 216 | | - - Co-developed-by: states that the patch was also created by another developer |
|---|
| 217 | | - along with the original author. This is useful at times when multiple |
|---|
| 218 | | - people work on a single patch. Note, this person also needs to have a |
|---|
| 219 | | - Signed-off-by: line in the patch as well. |
|---|
| 219 | + - Co-developed-by: states that the patch was co-created by several developers; |
|---|
| 220 | + it is a used to give attribution to co-authors (in addition to the author |
|---|
| 221 | + attributed by the From: tag) when multiple people work on a single patch. |
|---|
| 222 | + Every Co-developed-by: must be immediately followed by a Signed-off-by: of |
|---|
| 223 | + the associated co-author. Details and examples can be found in |
|---|
| 224 | + :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`. |
|---|
| 220 | 225 | |
|---|
| 221 | 226 | - Acked-by: indicates an agreement by another developer (often a |
|---|
| 222 | 227 | maintainer of the relevant code) that the patch is appropriate for |
|---|
| .. | .. |
|---|
| 226 | 231 | it to work. |
|---|
| 227 | 232 | |
|---|
| 228 | 233 | - Reviewed-by: the named developer has reviewed the patch for correctness; |
|---|
| 229 | | - see the reviewer's statement in Documentation/process/submitting-patches.rst |
|---|
| 234 | + see the reviewer's statement in :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` |
|---|
| 230 | 235 | for more detail. |
|---|
| 231 | 236 | |
|---|
| 232 | 237 | - Reported-by: names a user who reported a problem which is fixed by this |
|---|
| .. | .. |
|---|
| 253 | 258 | be examined in any detail. If there is any doubt at all, mail the patch |
|---|
| 254 | 259 | to yourself and convince yourself that it shows up intact. |
|---|
| 255 | 260 | |
|---|
| 256 | | - Documentation/process/email-clients.rst has some helpful hints on making |
|---|
| 257 | | - specific mail clients work for sending patches. |
|---|
| 261 | + :ref:`Documentation/process/email-clients.rst <email_clients>` has some |
|---|
| 262 | + helpful hints on making specific mail clients work for sending patches. |
|---|
| 258 | 263 | |
|---|
| 259 | 264 | - Are you sure your patch is free of silly mistakes? You should always |
|---|
| 260 | 265 | run patches through scripts/checkpatch.pl and address the complaints it |
|---|