Lines Matching +refs:is +refs:post +refs:merge
6 Sooner or later, the time comes when your work is ready to be presented to
17 When to post
20 There is a constant temptation to avoid posting patches before they are
21 completely "ready." For simple patches, that is not a problem. If the
22 work being done is complex, though, there is a lot to be gained by getting
23 feedback from the community before the work is complete. So you should
27 When posting code which is not yet considered ready for inclusion, it is a
45 - Make sure your code is compliant with the kernel coding style
49 benchmarks showing what the impact (or benefit) of your change is; a
52 - Be sure that you have the right to post the code. If this work was done
64 but, once again, attempting to save time here is not generally advisable
75 on the area of your patch and what is going on elsewhere, basing a patch
81 up patches is a bit of an art; some developers spend a long time figuring
85 - The patch series you post will almost certainly not be the series of
101 bug, rearranges a few structures, and reformats the code, there is a
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
108 scenario when the "git bisect" tool is used to find regressions; if the
109 result is a broken kernel, you will make life harder for developers and
123 the real bug is elsewhere. Whenever possible, a patch which adds new
128 done. When done properly, though, it is time well spent.
134 So now you have a perfect series of patches for posting, but the work is
139 - An optional "From" line naming the author of the patch. This line is
145 scope of the patch; it is the line that will show up in the "short form"
146 changelogs. This message is usually formatted with the relevant
155 patch. This description can be as long as is required; it should say
162 changelogs is a crucial but often-neglected art; it's worth spending
168 hunters wondering whether the patch is responsible for a problem they are
178 and the title when citing commits). If a problem is associated with
180 searching for a solution to the same problem. If the change is meant to
202 document; what follows here is a brief summary.
204 One tag is used to refer to earlier commits which introduced problems fixed by
209 Another tag is used for linking web pages with additional backgrounds or
216 latest public review posting of the patch; often this is automatically done
226 commit with such a tag is applied. Some bots monitoring mailing lists can
230 Another kind of tag is used to document who was involved in the development of
237 - Signed-off-by: this is a developer's certification that he or she has
238 the right to submit the patch for inclusion into the kernel. It is an
244 it is a used to give attribution to co-authors (in addition to the author
251 maintainer of the relevant code) that the patch is appropriate for
261 - Reported-by: names a user who reported a problem which is fixed by this
262 patch; this tag is used to give credit to the (often underappreciated)
265 the report, unless the report is not available on the web. The Link: tag
272 Be careful in the addition of tags to your patches, as only Cc: is appropriate
274 Reported-by: is fine most of the time as well, but ask for permission if
287 be examined in any detail. If there is any doubt at all, mail the patch
293 - Are you sure your patch is free of silly mistakes? You should always
297 look like, is not smarter than you. If fixing a checkpatch.pl complaint
305 When mailing patches, it is important to send copies to anybody who might
312 the MAINTAINERS file is the first place to look for these people.
330 When selecting recipients for a patch, it is good to have an idea of who
332 is possible to send patches directly to Linus Torvalds and have him merge
333 them, things are not normally done that way. Linus is busy, and there are
335 you will be wanting that maintainer to merge your patches. If there is no
336 obvious maintainer, Andrew Morton is often the patch target of last resort.
338 Patches need good subject lines. The canonical format for a patch line is
345 where "nn" is the ordinal number of the patch, "mm" is the total number of
346 patches in the series, and "subsys" is the name of the affected subsystem.
349 If you have a significant series of patches, it is customary to send an
350 introductory description as part zero. This convention is not universally