Lines Matching refs:patch
50 summary of the results should be included with the patch.
68 general rule, a patch should be based on the current mainline as found in
75 on the area of your patch and what is going on elsewhere, basing a patch
79 Only the most simple changes should be formatted as a single patch;
85 - The patch series you post will almost certainly not be the series of
93 patch. These changes can be small ("add a field to this structure") or
95 conceptually small and amenable to a one-line description. Each patch
100 changes in the same patch. If a single patch fixes a critical security
105 - Each patch should yield a kernel which builds and runs properly; if your
106 patch series is interrupted in the middle, the result should still be a
107 working kernel. Partial application of a patch series is a common
114 the most popular person on the kernel mailing list. A single patch can
119 patches, but to leave that infrastructure unused until the final patch
122 finger the last patch as the one which caused the problem, even though
123 the real bug is elsewhere. Whenever possible, a patch which adds new
126 Working to create the perfect patch series can be a frustrating process
135 not done quite yet. Each patch needs to be formatted into a message which
137 that end, each patch will be composed of the following:
139 - An optional "From" line naming the author of the patch. This line is
140 only necessary if you are passing on somebody else's patch via email,
143 - A one-line description of what the patch does. This message should be
145 scope of the patch; it is the line that will show up in the "short form"
147 subsystem name first, followed by the purpose of the patch. For
155 patch. This description can be as long as is required; it should say
156 what the patch does and why it should be applied to the kernel.
159 the author of the patch. Tags will be described in more detail below.
161 The items above, together, form the changelog for the patch. Writing good
166 whether the patch should be included, distributors and other maintainers
167 trying to decide whether a patch should be backported to other kernels, bug
168 hunters wondering whether the patch is responsible for a problem they are
176 needed additional information. If the patch fixes a bug, cite the commit
181 support other changes coming in later patch, say so. If internal APIs are
190 - The patch itself, in the unified ("-u") patch format. Using the "-p"
192 resulting patch easier for others to read.
195 the build process, for example, or editor backup files) in the patch. The
200 been associated with the development of this patch. They are described in
211 the right to submit the patch for inclusion into the kernel. It is an
216 - Co-developed-by: states that the patch was also created by another developer
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.
222 maintainer of the relevant code) that the patch is appropriate for
225 - Tested-by: states that the named person has tested the patch and found
228 - Reviewed-by: the named developer has reviewed the patch for correctness;
233 patch; this tag is used to give credit to the (often underappreciated)
237 - Cc: the named person received a copy of the patch and had the
244 Sending the patch
253 be examined in any detail. If there is any doubt at all, mail the patch
259 - Are you sure your patch is free of silly mistakes? You should always
268 the patch in their replies. Instead, just put the patch directly into your
292 the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
293 the patch itself; that will cause the stable team to get a notification
296 When selecting recipients for a patch, it is good to have an idea of who
297 you think will eventually accept the patch and get it merged. While it
302 obvious maintainer, Andrew Morton is often the patch target of last resort.
304 Patches need good subject lines. The canonical format for a patch line is
309 [PATCH nn/mm] subsys: one-line description of the patch
311 where "nn" is the ordinal number of the patch, "mm" is the total number of
313 Clearly, nn/mm can be omitted for a single, standalone patch.
321 In general, the second and following parts of a multi-part patch should be