Lines Matching full:your
21 have been told by your manager, "Go write a Linux driver for this
55 documented; do not expect people to adapt to you or your company's way
215 will learn the basics of getting your patch into the Linux kernel tree,
354 One of the best ways to put into practice your hacking skills is by fixing
357 improve your skills, and other developers will be aware of your presence.
405 If multiple people respond to your mail, the CC: list of recipients may
411 Remember to keep the context and the attribution of your replies intact,
412 keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
413 add your statements between the individual quoted sections instead of
416 If you add patches to your mail, make sure they are plain readable text
420 individual lines of your patch, which works only that way. Make sure you
422 good first test is to send the mail to yourself and try to apply your
423 own patch by yourself. If that doesn't work, get your mail program fixed
443 Remember, this is part of getting your patch into the kernel. You have
444 to be able to take criticism and comments about your patches, evaluate
445 them at a technical level and either rework your patches or provide
447 If there are no responses to your posting, wait a few days and try
452 - expect your patch to be accepted without question
459 You have to be cooperative, and willing to adapt your idea to fit within
460 the kernel. Or at least be willing to prove your idea is worth it.
464 It is normal that the answers to your first patch might simply be a list
465 of a dozen things you should correct. This does **not** imply that your
467 personally. Simply correct all issues raised against your patch and
478 Good things to say regarding your proposed changes:
514 recommended that you check your emails to make sure they make sense in
518 Break up your changes
524 the exact opposite of what companies are used to doing. Your proposal
528 as a dumping ground for your feature. However, don't send 50 emails at
529 one time to a mailing list, your patch series should be smaller than
534 1) Small patches increase the likelihood that your patches will be
564 solution and working together with the community and discussing your
566 get feedback to improve your work, but also keep your changes in small
567 chunks that they may get already accepted, even when your whole task is
574 Justify your change
577 Along with breaking up your patches, it is very important for you to let
582 Document your change
585 When sending in your patches, pay special attention to what you say in
586 the text in your email. This information will become the ChangeLog