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
304 Note, however, that some subsystem maintainers want to come to their own
311 least a notification of the change, so that some information makes its way
339 tools, so that they may comment on specific portions of your code.
355 your e-mail client so that it sends your patches untouched.
362 it is preferred that you store your patch on an Internet-accessible
364 that if your patch exceeds 300 kB, it almost certainly needs to be broken up
373 or questions that do not lead to a code change should almost certainly
374 bring about a comment or changelog entry so that the next reviewer better
379 reviewers sometimes get grumpy. Even in that case, though, respond
390 but the development process works more smoothly than that now. You should
391 receive comments within a week or so; if that does not happen, make sure
392 that you have sent your patches to the right place. Wait for a minimum of
410 To improve tracking of who did what, especially with patches that can
413 patches that are being emailed around.
416 patch, which certifies that you wrote it or otherwise have the right to
422 By making a contribution to this project, I certify that:
428 (b) The contribution is based upon previous work that, to the best
430 license and I have the right under that license to submit that
440 (d) I understand and agree that this project and the contribution
441 are public and that a record of the contribution (including all
462 make him endorse your bugs. To solve this problem, it is recommended that
466 enclosed in square brackets, is noticeable enough to make it obvious that
475 and protect the submitter from complaints. Note that under no circumstances
506 The Signed-off-by: tag indicates that the signer was involved in the
507 development of the patch, or that he/she was in the patch's delivery path.
513 Acked-by: is often used by the maintainer of the affected code when that
516 Acked-by: is not as formal as Signed-off-by:. It is a record that the acker
519 into an Acked-by: (but note that it is usually better to ask for an
525 the part which affects that maintainer's code. Judgement should be used here.
532 person it names - but it should indicate that this person was copied on the
533 patch. This tag documents that potentially interested parties
541 hopefully inspires them to help us again in the future. Please note that if
545 A Tested-by: tag indicates that the patch has been successfully tested (in
546 some environment) by the person named. This tag informs maintainers that
550 Reviewed-by:, instead, indicates that the patch has been reviewed and found
555 By offering my Reviewed-by: tag, I state that:
565 (c) While there may be things that could be improved with this
566 submission, I believe that it is, at this time, (1) a
572 warranties or guarantees that it will achieve its stated
575 A Reviewed-by tag is a statement of opinion that the patch is an
584 A Suggested-by: tag indicates that the patch idea is suggested by the person
585 named and ensures credit to the person for the idea. Please note that this
591 A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
602 that, if you have your patches stored in a git repository, proper patch
631 support that - since because the sequence number is zero-padded,
638 describe the patch which that email contains. The "summary
643 Bear in mind that the "summary phrase" of your email becomes a
644 globally-unique identifier for that patch. It propagates all the way
647 google for the "summary phrase" to read discussion regarding that
648 patch. It will also be the only thing that people may quickly see
656 succinct and descriptive, but that is what a well-written summary
667 that developers understand the order in which the patches should be
668 applied and that they have reviewed or applied all of the patches in
688 since forgotten the immediate details of the discussion that might
694 enough that it is likely that someone searching for the patch can find
711 use diffstat options "-p 1 -w 70" so that filenames are listed from
725 "git pull" operation. Note, however, that pulling patches from a developer
749 commits; that increases their confidence that the request actually came
758 Once you have prepared a patch series in git that you wish to have somebody