1
0
Fork 0

SubmittingPatches: make Subject examples match the de facto standard

The examples should better match what kernel developers actually expect,
so that they set a good example both for this project and for other
projects with similar development processes.

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
hifive-unleashed-5.1
Alex Henrie 2015-09-20 14:11:19 +02:00 committed by Jonathan Corbet
parent 2b71920e60
commit e12d74623d
1 changed files with 4 additions and 4 deletions

View File

@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary
should do.
The "summary phrase" may be prefixed by tags enclosed in square
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
considered part of the summary phrase, but describe how the patch
brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
not considered part of the summary phrase, but describe how the patch
should be treated. Common tags might include a version descriptor if
the multiple versions of the patch have been sent out in response to
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
@ -672,8 +672,8 @@ the patch series.
A couple of example Subjects:
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCHv2 001/207] x86: fix eflags tracking
Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCH v2 01/27] x86: fix eflags tracking
The "from" line must be the very first line in the message body,
and has the form: