Lines Matching refs:patch
45 summary of the results should be included with the patch.
62 general rule, a patch should be based on the current mainline as found in
69 on the area of your patch and what is going on elsewhere, basing a patch
73 Only the most simple changes should be formatted as a single patch;
79 - The patch series you post will almost certainly not be the series of
87 patch. These changes can be small ("add a field to this structure") or
89 conceptually small and amenable to a one-line description. Each patch
94 changes in the same patch. If a single patch fixes a critical security
99 - Each patch should yield a kernel which builds and runs properly; if your
100 patch series is interrupted in the middle, the result should still be a
101 working kernel. Partial application of a patch series is a common
108 the most popular person on the kernel mailing list. A single patch can
113 patches, but to leave that infrastructure unused until the final patch
116 finger the last patch as the one which caused the problem, even though
117 the real bug is elsewhere. Whenever possible, a patch which adds new
120 Working to create the perfect patch series can be a frustrating process
128 not done quite yet. Each patch needs to be formatted into a message which
130 that end, each patch will be composed of the following:
132 - An optional "From" line naming the author of the patch. This line is
133 only necessary if you are passing on somebody else's patch via email,
136 - A one-line description of what the patch does. This message should be
138 scope of the patch; it is the line that will show up in the "short form"
140 subsystem name first, followed by the purpose of the patch. For
146 patch. This description can be as long as is required; it should say
147 what the patch does and why it should be applied to the kernel.
150 the author of the patch. Tags will be described in more detail below.
152 The items above, together, form the changelog for the patch. Writing good
157 whether the patch should be included, distributors and other maintainers
158 trying to decide whether a patch should be backported to other kernels, bug
159 hunters wondering whether the patch is responsible for a problem they are
167 needed additional information. If the patch fixes a bug, cite the commit
172 support other changes coming in later patch, say so. If internal APIs are
181 - The patch itself, in the unified ("-u") patch format. Using the "-p"
183 resulting patch easier for others to read.
186 the build process, for example, or editor backup files) in the patch. The
191 been associated with the development of this patch. They are described in
200 the right to submit the patch for inclusion into the kernel. It is an
206 maintainer of the relevant code) that the patch is appropriate for
209 - Tested-by: states that the named person has tested the patch and found
212 - Reviewed-by: the named developer has reviewed the patch for correctness;
217 patch; this tag is used to give credit to the (often underappreciated)
221 - Cc: the named person received a copy of the patch and had the
236 be examined in any detail. If there is any doubt at all, mail the patch
242 - Are you sure your patch is free of silly mistakes? You should always
251 the patch in their replies. Instead, just put the patch directly into your
275 the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
276 the patch itself; that will cause the stable team to get a notification
279 When selecting recipients for a patch, it is good to have an idea of who
280 you think will eventually accept the patch and get it merged. While it
285 obvious maintainer, Andrew Morton is often the patch target of last resort.
287 Patches need good subject lines. The canonical format for a patch line is
290 [PATCH nn/mm] subsys: one-line description of the patch
292 where "nn" is the ordinal number of the patch, "mm" is the total number of
294 Clearly, nn/mm can be omitted for a single, standalone patch.
302 In general, the second and following parts of a multi-part patch should be