Lines Matching refs:it

23 When posting code which is not yet considered ready for inclusion, it is a
76 out how to do it in the way that the community expects.  There are a few
91    verified to do what it says it does.
96    good chance that it will be passed over and the important fix will be
106  - Do not overdo it, though.  One developer once posted a set of edits
109    be reasonably large as long as it still contains a single *logical*
122 done.  When done properly, though, it is time well spent.
134    but it never hurts to add it when in doubt.
137    enough for a reader who sees it with no other context to figure out the
138    scope of the patch; it is the line that will show up in the "short form"
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.
153 changelogs is a crucial but often-neglected art; it's worth spending
188 pass it to diff with the "-X" option.
210    it to work.
222    opportunity to comment on it.
237    to yourself and convince yourself that it shows up intact.
243    run patches through scripts/checkpatch.pl and address the complaints it
247    would make the code worse, don't do it.
250 attachments; that makes it much harder for reviewers to quote sections of
254 When mailing patches, it is important to send copies to anybody who might
255 be interested in it.  Unlike some other projects, the kernel encourages
279 When selecting recipients for a patch, it is good to have an idea of who
280 you think will eventually accept the patch and get it merged.  While it
296 If you have a significant series of patches, it is customary to send an
298 followed though; if you use it, remember that information in the
299 introduction does not make it into the kernel changelogs.  So please ensure