Lines Matching refs:patch
51 summary of the results should be included with the patch.
69 general rule, a patch should be based on the current mainline as found in
76 on the area of your patch and what is going on elsewhere, basing a patch
80 Only the most simple changes should be formatted as a single patch;
86 - The patch series you post will almost certainly not be the series of
94 patch. These changes can be small ("add a field to this structure") or
96 conceptually small and amenable to a one-line description. Each patch
101 changes in the same patch. If a single patch fixes a critical security
106 - Each patch should yield a kernel which builds and runs properly; if your
107 patch series is interrupted in the middle, the result should still be a
108 working kernel. Partial application of a patch series is a common
115 the most popular person on the kernel mailing list. A single patch can
120 patches, but to leave that infrastructure unused until the final patch
123 finger the last patch as the one which caused the problem, even though
124 the real bug is elsewhere. Whenever possible, a patch which adds new
127 Working to create the perfect patch series can be a frustrating process
136 not done quite yet. Each patch needs to be formatted into a message which
138 that end, each patch will be composed of the following:
140 - An optional "From" line naming the author of the patch. This line is
141 only necessary if you are passing on somebody else's patch via email,
144 - A one-line description of what the patch does. This message should be
146 scope of the patch; it is the line that will show up in the "short form"
148 subsystem name first, followed by the purpose of the patch. For
156 patch. This description can be as long as is required; it should say
157 what the patch does and why it should be applied to the kernel.
160 the author of the patch. Tags will be described in more detail below.
162 The items above, together, form the changelog for the patch. Writing good
167 whether the patch should be included, distributors and other maintainers
168 trying to decide whether a patch should be backported to other kernels, bug
169 hunters wondering whether the patch is responsible for a problem they are
177 needed additional information. If the patch fixes a bug, cite the commit
182 support other changes coming in later patch, say so. If internal APIs are
191 - The patch itself, in the unified ("-u") patch format. Using the "-p"
193 resulting patch easier for others to read.
196 the build process, for example, or editor backup files) in the patch. The
201 been associated with the development of this patch. They are described in
214 the right to submit the patch for inclusion into the kernel. It is an
219 - Co-developed-by: states that the patch was co-created by several developers;
221 attributed by the From: tag) when multiple people work on a single patch.
227 maintainer of the relevant code) that the patch is appropriate for
230 - Tested-by: states that the named person has tested the patch and found
233 - Reviewed-by: the named developer has reviewed the patch for correctness;
238 patch; this tag is used to give credit to the (often underappreciated)
242 - Cc: the named person received a copy of the patch and had the
249 Sending the patch
258 be examined in any detail. If there is any doubt at all, mail the patch
264 - Are you sure your patch is free of silly mistakes? You should always
273 the patch in their replies. Instead, just put the patch directly into your
297 the patch. Also add a "Cc: stable@vger.kernel.org" to the tags within
298 the patch itself; that will cause the stable team to get a notification
301 When selecting recipients for a patch, it is good to have an idea of who
302 you think will eventually accept the patch and get it merged. While it
307 obvious maintainer, Andrew Morton is often the patch target of last resort.
309 Patches need good subject lines. The canonical format for a patch line is
314 [PATCH nn/mm] subsys: one-line description of the patch
316 where "nn" is the ordinal number of the patch, "mm" is the total number of
318 Clearly, nn/mm can be omitted for a single, standalone patch.
326 In general, the second and following parts of a multi-part patch should be