Lines Matching refs:that
41 Note, however, that you may not want to develop against the mainline tree
44 in the MAINTAINERS file to find that tree, or simply ask the maintainer if
48 in the next section), but that is the hard way to do kernel development.
61 change is in - that makes the resultant diff a lot easier to read.
110 5000 lines of a new feature, there must be an underlying problem that
111 motivated you to do this work. Convince the reviewer that there is a
112 problem worth fixing and that it makes sense for them to read past the
116 pretty convincing, but not all bugs are that blatant. Even if the
118 it can have on users. Keep in mind that the majority of Linux
120 vendor/product-specific trees that cherry-pick only specific patches
121 from upstream, so include anything that could help route your change
127 include numbers that back them up. But also describe non-obvious
131 optimization so that the reviewer can weigh costs against benefits.
135 in plain English for the reviewer to verify that the code is behaving
143 long, that's a sign that you probably need to split up your patch.
148 say that this is version N of the patch (series). Don't expect the
150 URLs to find the patch description and put that into the patch.
160 If the patch fixes a logged bug entry, refer to that bug entry by
163 redirector with a Message-Id, to ensure that the links cannot become
168 bug, summarize the relevant points of the discussion that led to the
183 collisions with shorter IDs a real possibility. Bear in mind that, even if
184 there is no collision with your six-character ID now, that condition may
209 driver which uses that new API, separate those into two patches.
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
220 complete, that is OK. Simply note "this patch depends on patch X"
224 ensure that the kernel builds and runs properly after each patch in the
250 (scripts/checkpatch.pl). Note, though, that the style checker should be
255 - ERROR: things that are very likely to be wrong
259 You should be able to justify all violations that remain in your
267 to code that they maintain; look through the MAINTAINERS file and the
275 last resort, but the volume on that list has caused a number of developers
292 If you have a patch that fixes an exploitable security bug, send that patch
297 Patches that fix a severe bug in a released kernel should be directed
306 Note, however, that some subsystem maintainers want to come to their own
313 least a notification of the change, so that some information makes its way
341 tools, so that they may comment on specific portions of your code.
357 your e-mail client so that it sends your patches untouched.
364 it is preferred that you store your patch on an Internet-accessible
366 that if your patch exceeds 300 kB, it almost certainly needs to be broken up
375 or questions that do not lead to a code change should almost certainly
376 bring about a comment or changelog entry so that the next reviewer better
381 reviewers sometimes get grumpy. Even in that case, though, respond
392 but the development process works more smoothly than that now. You should
393 receive comments within a week or so; if that does not happen, make sure
394 that you have sent your patches to the right place. Wait for a minimum of
412 To improve tracking of who did what, especially with patches that can
415 patches that are being emailed around.
418 patch, which certifies that you wrote it or otherwise have the right to
424 By making a contribution to this project, I certify that:
430 (b) The contribution is based upon previous work that, to the best
432 license and I have the right under that license to submit that
442 (d) I understand and agree that this project and the contribution
443 are public and that a record of the contribution (including all
464 make him endorse your bugs. To solve this problem, it is recommended that
468 enclosed in square brackets, is noticeable enough to make it obvious that
477 and protect the submitter from complaints. Note that under no circumstances
508 The Signed-off-by: tag indicates that the signer was involved in the
509 development of the patch, or that he/she was in the patch's delivery path.
515 Acked-by: is often used by the maintainer of the affected code when that
518 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
521 into an Acked-by: (but note that it is usually better to ask for an
527 the part which affects that maintainer's code. Judgement should be used here.
534 person it names - but it should indicate that this person was copied on the
535 patch. This tag documents that potentially interested parties
543 hopefully inspires them to help us again in the future. Please note that if
547 A Tested-by: tag indicates that the patch has been successfully tested (in
548 some environment) by the person named. This tag informs maintainers that
552 Reviewed-by:, instead, indicates that the patch has been reviewed and found
557 By offering my Reviewed-by: tag, I state that:
567 (c) While there may be things that could be improved with this
568 submission, I believe that it is, at this time, (1) a
574 warranties or guarantees that it will achieve its stated
577 A Reviewed-by tag is a statement of opinion that the patch is an
586 A Suggested-by: tag indicates that the patch idea is suggested by the person
587 named and ensures credit to the person for the idea. Please note that this
593 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
604 that, if you have your patches stored in a git repository, proper patch
633 support that - since because the sequence number is zero-padded,
640 describe the patch which that email contains. The "summary
645 Bear in mind that the "summary phrase" of your email becomes a
646 globally-unique identifier for that patch. It propagates all the way
649 google for the "summary phrase" to read discussion regarding that
650 patch. It will also be the only thing that people may quickly see
658 succinct and descriptive, but that is what a well-written summary
669 that developers understand the order in which the patches should be
670 applied and that they have reviewed or applied all of the patches in
690 since forgotten the immediate details of the discussion that might
696 enough that it is likely that someone searching for the patch can find
713 use diffstat options "-p 1 -w 70" so that filenames are listed from
740 "git pull" operation. Note, however, that pulling patches from a developer
764 commits; that increases their confidence that the request actually came
773 Once you have prepared a patch series in git that you wish to have somebody