Lines Matching full:patch
50 summary of the results should be included with the patch.
60 Patch preparation
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
131 Patch formatting and changelogs
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 the patch came into being. They are described in detail in the
205 the patch::
210 details, for example a report about a bug fixed by the patch or a document
211 with a specification implemented by the patch::
215 Many maintainers when applying a patch also add this tag to link to the
216 latest public review posting of the patch; often this is automatically done
221 the patch. Each of these uses this format::
228 the right to submit the patch for inclusion into the kernel. It is an
233 - Co-developed-by: states that the patch was co-created by several developers;
235 attributed by the From: tag) when multiple people work on a single patch.
241 maintainer of the relevant code) that the patch is appropriate for
244 - Tested-by: states that the named person has tested the patch and found
247 - Reviewed-by: the named developer has reviewed the patch for correctness;
252 patch; this tag is used to give credit to the (often underappreciated)
256 - Cc: the named person received a copy of the patch and had the
265 Sending the patch
274 be examined in any detail. If there is any doubt at all, mail the patch
280 - Are you sure your patch is free of silly mistakes? You should always
289 the patch in their replies. Instead, just put the patch directly into your
313 the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
314 the patch itself; that will cause the stable team to get a notification
317 When selecting recipients for a patch, it is good to have an idea of who
318 you think will eventually accept the patch and get it merged. While it
323 obvious maintainer, Andrew Morton is often the patch target of last resort.
325 Patches need good subject lines. The canonical format for a patch line is
330 [PATCH nn/mm] subsys: one-line description of the patch
332 where "nn" is the ordinal number of the patch, "mm" is the total number of
334 Clearly, nn/mm can be omitted for a single, standalone patch.
342 In general, the second and following parts of a multi-part patch should be