Lines Matching full:should

24 feedback from the community before the work is complete.  So you should
38 There are a number of things which should be done before you consider
49  - Does your change have performance implications?  If so, you should run
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
80 Only the most simple changes should be formatted as a single patch;
81 everything else should be made as a logical series of changes.  Splitting
93  - Each logically independent change should be formatted as a separate
95    large (adding a significant new driver, for example), but they should be
97    should make a specific change which can be reviewed on its own and
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
121    in the series enables the whole thing.  This temptation should be
125    code should make that code active immediately.
144  - A one-line description of what the patch does.  This message should be
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.
164 another moment discussing this issue.  When writing a changelog, you should
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
174 To that end, the summary line should describe the effects of and motivation
183 changed, detail those changes and how other developers should respond.  In
188 Needless to say, the changelog should be the text used when committing the
195 You should avoid including changes to irrelevant files (those generated by
252 Before you mail your patches, there are a couple of other things you should
264  - Are you sure your patch is free of silly mistakes?  You should always
267    embodiment of a fair amount of thought about what kernel patches should
271 Patches should always be sent as plain text.  Please do not send them as
280 copies should go to:
295  - If you are fixing a bug, think about whether the fix should go into the
296    next stable update.  If so, stable@vger.kernel.org should get a copy of
326 In general, the second and following parts of a multi-part patch should be