Documentation/process/5.Posting.rst

23 feedback from the community before the work is complete.  So you should
37 There are a number of things which should be done before you consider
48  - Does your change have performance implications?  If so, you should run
50    summary of the results should be included with the patch.
68 general rule, a patch should be based on the current mainline as found in
79 Only the most simple changes should be formatted as a single patch;
80 everything else should be made as a logical series of changes.  Splitting
92  - Each logically independent change should be formatted as a separate
94    large (adding a significant new driver, for example), but they should be
96    should make a specific change which can be reviewed on its own and
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
120    in the series enables the whole thing.  This temptation should be
124    code should make that code active immediately.
143  - A one-line description of what the patch does.  This message should be
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.
163 another moment discussing this issue.  When writing a changelog, you should
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
173 To that end, the summary line should describe the effects of and motivation
182 changed, detail those changes and how other developers should respond.  In
187 Needless to say, the changelog should be the text used when committing the
194 You should avoid including changes to irrelevant files (those generated by
264    correctly. Note, this tag should be followed by a Closes: tag pointing to
281 Before you mail your patches, there are a couple of other things you should
293  - Are you sure your patch is free of silly mistakes?  You should always
296    embodiment of a fair amount of thought about what kernel patches should
300 Patches should always be sent as plain text.  Please do not send them as
309 copies should go to:
324  - If you are fixing a bug, think about whether the fix should go into the
325    next stable update.  If so, stable@vger.kernel.org should get a copy of
355 In general, the second and following parts of a multi-part patch should be