Lines Matching refs:be

3 Sooner or later, the time comes when your work is ready to be presented to
9 more information can also be found in the files SubmittingPatches,
18 work being done is complex, though, there is a lot to be gained by getting
25 which remains to be done and any known problems.  Fewer people will look at
26 patches which are known to be half-baked, but those who do will come in
32 There are a number of things which should be done before you consider
45    summary of the results should be included with the patch.
48    for an employer, the employer likely has a right to the work and must be
57 The preparation of patches for posting can be a surprising amount of work,
61 Patches must be prepared against a specific version of the kernel.  As a
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
79  - The patch series you post will almost certainly not be the series of
81    changes you have made need to be considered in their final form, then
86  - Each logically independent change should be formatted as a separate
87    patch.  These changes can be small ("add a field to this structure") or
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
96    good chance that it will be passed over and the important fix will be
100    patch series is interrupted in the middle, the result should still be a
109    be reasonably large as long as it still contains a single *logical*
112  - It can be tempting to add a whole new infrastructure with a series of
114    in the series enables the whole thing.  This temptation should be
120 Working to create the perfect patch series can be a frustrating process
128 not done quite yet.  Each patch needs to be formatted into a message which
130 that end, each patch will be composed of the following:
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.
150    the author of the patch.  Tags will be described in more detail below.
155 bear in mind that a number of different people will be reading your words.
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
175 be reading your changelog, the better that changelog (and the kernel as a
176 whole) will be.
178 Needless to say, the changelog should be the text used when committing the
179 change to a revision control system.  It will be followed by:
202    which can be found in Documentation/SubmittingPatches.  Code without a
203    proper signoff cannot be merged into the mainline.
236    be examined in any detail.  If there is any doubt at all, mail the patch
249 Patches should always be sent as plain text.  Please do not send them as
255 be interested in it.  Unlike some other projects, the kernel encourages
264    those who might be working there now.  Using git to see who else has
265    modified the files you are working on can be helpful.
284 you will be wanting that maintainer to merge your patches.  If there is no
294 Clearly, nn/mm can be omitted for a single, standalone patch.
302 In general, the second and following parts of a multi-part patch should be