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,
361 One of the best ways to put into practice your hacking skills is by fixing
364 improve your skills, and other developers will be aware of your presence.
406 If multiple people respond to your mail, the CC: list of recipients may
412 Remember to keep the context and the attribution of your replies intact,
413 keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
414 add your statements between the individual quoted sections instead of
417 If you add patches to your mail, make sure they are plain readable text
421 individual lines of your patch, which works only that way. Make sure you
423 good first test is to send the mail to yourself and try to apply your
424 own patch by yourself. If that doesn't work, get your mail program fixed
444 Remember, this is part of getting your patch into the kernel. You have
445 to be able to take criticism and comments about your patches, evaluate
446 them at a technical level and either rework your patches or provide
448 If there are no responses to your posting, wait a few days and try
453 - expect your patch to be accepted without question
460 You have to be cooperative, and willing to adapt your idea to fit within
461 the kernel. Or at least be willing to prove your idea is worth it.
465 It is normal that the answers to your first patch might simply be a list
466 of a dozen things you should correct. This does **not** imply that your
468 personally. Simply correct all issues raised against your patch and
479 Good things to say regarding your proposed changes:
515 recommended that you check your emails to make sure they make sense in
519 Break up your changes
525 the exact opposite of what companies are used to doing. Your proposal
529 as a dumping ground for your feature. However, don't send 50 emails at
530 one time to a mailing list, your patch series should be smaller than
535 1) Small patches increase the likelihood that your patches will be
565 solution and working together with the community and discussing your
567 get feedback to improve your work, but also keep your changes in small
568 chunks that they may get already accepted, even when your whole task is
575 Justify your change
578 Along with breaking up your patches, it is very important for you to let
583 Document your change
586 When sending in your patches, pay special attention to what you say in
587 the text in your email. This information will become the ChangeLog