Lines Matching refs:change
8 For a person or company who wishes to submit a change to the Linux
11 can greatly increase the chances of your change being accepted.
61 change is in - that makes the resultant diff a lot easier to read.
72 vi $MYFILE # make your change
121 from upstream, so include anything that could help route your change
134 about it in technical detail. It's important to describe the change
157 to do frotz", as if you are giving orders to the codebase to change
185 change five years from now.
211 On the other hand, if you make a single change to numerous files,
212 group those changes into a single patch. Thus a single logical change
216 change that can be verified by reviewers. Each patch should be justifiable
219 If one patch depends on another patch in order for a change to be
223 When dividing your change into a series of patches, take special care to
313 least a notification of the change, so that some information makes its way
351 decreasing the likelihood of your MIME-attached change being accepted.
375 or questions that do not lead to a code change should almost certainly
388 After you have submitted your change, be patient and wait. Reviewers are
463 the code, but then it is very impolite to change one submitter's code and
478 can you change the author's identity (the From header), as it is the one