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
311 If changes affect userland-kernel interfaces, please send the MAN-PAGES
314 into the manual pages.  User-space API changes should also be copied to
339 on the changes you are submitting.  It is important for a kernel
340 developer to be able to "quote" your changes, using standard e-mail
362 Large changes are not appropriate for mailing lists, and some
379 Be sure to tell the reviewers what changes you are making and to thank them
466 the nature of your changes. While there is nothing mandatory about this, it
469 you are responsible for last-minute changes. Example :
476 want at the same time to credit the author, track changes, merge the fix,
656 characters, and it must describe both what the patch changes, as well
755   to get these changes:
818   Some strategies to get difficult or controversial changes in.