Lines Matching full:your
3 Submitting patches: the essential guide to getting your code into the kernel
9 can greatly increase the chances of your change being accepted.
22 control system; if you use ``git`` to prepare your patches, you'll find much
25 your life as a kernel developer easier.
48 If you must generate your patches by hand, use ``diff -up`` or ``diff -uprN``
53 generated by :manpage:`diff(1)`. When creating your patch, make sure to
68 vi $MYFILE # make your change
73 or unmodified kernel source tree, and generate a ``diff`` against your
87 Make sure your patch does not include any extra files which do not
88 belong in a patch submission. Make sure to review your patch -after-
91 If your changes produce a lot of deltas, you need to split them into
94 very important if you want your patch accepted.
102 2) Describe your changes
105 Describe your problem. Whether your patch is a one-line bug fix or
117 from upstream, so include anything that could help route your change
126 different workloads. Describe the expected downsides of your
134 The maintainer will thank you if you write your patch description in a
138 Solve only one problem per patch. If your description starts to get
139 long, that's a sign that you probably need to split up your patch.
151 Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
162 However, try to make your explanation understandable without external
180 there is no collision with your six-character ID now, that condition may
183 If your patch fixes a bug in a specific commit, e.g. you found an issue using
201 3) Separate your changes
206 For example, if your changes include both bug fixes and performance
208 or more patches. If your changes include an API update, and a new
221 in your patch description.
223 When dividing your change into a series of patches, take special care to
226 splitting your patch series at any point; they will not thank you if you
229 If you cannot condense your patch set into a smaller set of patches,
234 4) Style-check your changes
237 Check your patch for basic style violations, details of which can be
241 the reviewers time and will get your patch rejected, probably
247 moving the code and your changes. This greatly aids review of the
251 Check your patches with the patch style checker prior to submission
253 viewed as a guide, not as a replacement for human judgment. If your code
261 You should be able to justify all violations that remain in your
265 5) Select the recipients for your patch
276 of your patch set. linux-kernel@vger.kernel.org functions as a list of
279 list; your patch will probably get more attention there. Please do not
291 Linus directly, so typically you should do your best to -avoid-
304 into the sign-off area of your patch (note, NOT an email recipient). You
345 developer to be able to "quote" your changes, using standard e-mail
346 tools, so that they may comment on specific portions of your code.
352 Be wary of your editor's word-wrap corrupting your patch,
353 if you choose to cut-n-paste your patch.
357 attachment as plain text, making it impossible to comment on your
359 decreasing the likelihood of your MIME-attached change being accepted.
361 Exception: If your mailer is mangling patches then someone may ask
365 for hints about configuring your e-mail client so that it sends your patches
372 maintainers. If your patch, uncompressed, exceeds 300 kB in size,
373 it is preferred that you store your patch on an Internet-accessible
374 server, and provide instead a URL (link) pointing to your patch. But note
375 that if your patch exceeds 300 kB, it almost certainly needs to be broken up
381 Your patch will almost certainly get comments from reviewers on ways in
397 After you have submitted your change, be patient and wait. Reviewers are
398 busy people and may not get to your patch right away.
403 that you have sent your patches to the right place. Wait for a minimum of
412 convention to prefix your subject line with [PATCH]. This lets Linus
418 11) Sign your work - the Developer's Certificate of Origin
462 using your real name (sorry, no pseudonyms or anonymous contributions.)
470 exactly the same in your tree and the submitters'. If you stick strictly to
474 make him endorse your bugs. To solve this problem, it is recommended that
476 the nature of your changes. While there is nothing mandatory about this, it
477 seems like prepending the description with your mail and/or name, all
511 tracking your trees, and to people trying to troubleshoot bugs in your
630 increase the likelihood of your patch getting into the kernel.
642 which stable kernel versions should receive your fix. This is the preferred
652 that, if you have your patches stored in a ``git`` repository, proper patch
693 Bear in mind that the ``summary phrase`` of your email becomes a
821 be a good way to find developers who can sign your key.
826 created with your private key. You will also have the opportunity to add a
834 When generating your pull request, use the signed tag as the target. A