Documentation/development-process/5.Posting

19 feedback from the community before the work is complete.  So you should
32 There are a number of things which should be done before you consider
43  - Does your change have performance implications?  If so, you should run
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
73 Only the most simple changes should be formatted as a single patch;
74 everything else should be made as a logical series of changes.  Splitting
86  - Each logically independent change should be formatted as a separate
88    large (adding a significant new driver, for example), but they should be
90    should make a specific change which can be reviewed on its own and
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
114    in the series enables the whole thing.  This temptation should be
118    code should make that code active immediately.
136  - A one-line description of what the patch does.  This message should be
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.
154 another moment discussing this issue.  When writing a changelog, you should
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
164 To that end, the summary line should describe the effects of and motivation
173 changed, detail those changes and how other developers should respond.  In
178 Needless to say, the changelog should be the text used when committing the
185 You should avoid including changes to irrelevant files (those generated by
230 Before you mail your patches, there are a couple of other things you should
242  - Are you sure your patch is free of silly mistakes?  You should always
245    embodiment of a fair amount of thought about what kernel patches should
249 Patches should always be sent as plain text.  Please do not send them as
258 copies should go to:
273  - If you are fixing a bug, think about whether the fix should go into the
274    next stable update.  If so, stable@vger.kernel.org should get a copy of
302 In general, the second and following parts of a multi-part patch should be