Lines Matching refs:changes

57 All changes to the Linux kernel occur in the form of patches, as
95 If your changes produce a lot of deltas, you need to split them into
106 2) Describe your changes.
155 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
201 3) Separate your changes.
206 For example, if your changes include both bug fixes and performance
207 enhancements for a single driver, separate those changes into two
208 or more patches.  If your changes include an API update, and a new
212 group those changes into a single patch.  Thus a single logical change
234 4) Style-check your changes.
245 moving the code and your changes.  This greatly aids review of the
286 Linus Torvalds is the final arbiter of all changes accepted into the
309 If changes affect userland-kernel interfaces, please send the MAN-PAGES
312 into the manual pages.  User-space API changes should also be copied to
337 on the changes you are submitting.  It is important for a kernel
338 developer to be able to "quote" your changes, using standard e-mail
360 Large changes are not appropriate for mailing lists, and some
377 Be sure to tell the reviewers what changes you are making and to thank them
464 the nature of your changes. While there is nothing mandatory about this, it
467 you are responsible for last-minute changes. Example :
474 want at the same time to credit the author, track changes, merge the fix,
654 characters, and it must describe both what the patch changes, as well
740   to get these changes:"
803   Some strategies to get difficult or controversial changes in.