Lines Matching refs:should

62 Patches should be based in the root kernel source directory,
76 To create a patch for multiple files, you should unpack a "vanilla",
88 the build process, and should be ignored in any diff(1)-generated
151 I.e., the patch (series) and its description should be self-contained.
181 You should also be sure to use at least the first twelve characters of the
215 The point to remember is that each patch should make an easily understood
216 change that can be verified by reviewers.  Each patch should be justifiable
243 another -- in this case you should not modify the moved code at all in
250 (scripts/checkpatch.pl).  Note, though, that the style checker should be
259 You should be able to justify all violations that remain in your
266 You should always copy the appropriate subsystem maintainer(s) on any patch
273 You should also normally choose at least one mailing list to receive a copy
289 Linus directly, so typically you should do your best to -avoid-
295 obviously, the patch should not be sent to any public lists.
297 Patches that fix a severe bug in a released kernel should be directed
305 conclusions on which patches should go to the stable trees.  The networking
312 into the manual pages.  User-space API changes should also be copied to
341 For this reason, all patches should be submitting e-mail "inline".
373 or questions that do not lead to a code change should almost certainly
390 but the development process works more smoothly than that now.  You should
459 rule (c), you should ask the submitter to rediff, but this is a totally
525 the part which affects that maintainer's code.  Judgement should be used here.
526 When in doubt people should refer to the original discussion in the mailing
532 person it names - but it should indicate that this person was copied on the
586 tag should not be added without the reporter's permission, especially if the
594 which stable kernel versions should receive your fix. This is the preferred
601 This section describes how the patch itself should be formatted.  Note
634 The "subsystem" in the email's Subject should identify which
637 The "summary phrase" in the email's Subject should concisely
639 phrase" should not be a filename.  Do not use the same "summary
657 should do.
662 should be treated.  Common tags might include a version descriptor if
667 that developers understand the order in which the patches should be
687 changelog, so should make sense to a competent reader who has long
705 maintainer, not suitable for the permanent changelog, should also go
732 A pull request should have [GIT] or [PULL] in the subject line.  The
733 request itself should include the repository name and the branch of
734 interest on a single line; it should look something like:
742 A pull request should also include an overall message saying what will be