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
214 will learn the basics of getting your patch into the Linux kernel tree,
353 One of the best ways to put into practice your hacking skills is by fixing
356 improve your skills, and other developers will be aware of your presence.
404 If multiple people respond to your mail, the CC: list of recipients may
410 Remember to keep the context and the attribution of your replies intact,
411 keep the "John Kernelhacker wrote ...:" lines at the top of your reply, and
412 add your statements between the individual quoted sections instead of
415 If you add patches to your mail, make sure they are plain readable text
419 individual lines of your patch, which works only that way. Make sure you
421 good first test is to send the mail to yourself and try to apply your
422 own patch by yourself. If that doesn't work, get your mail program fixed
442 Remember, this is part of getting your patch into the kernel.  You have
443 to be able to take criticism and comments about your patches, evaluate
444 them at a technical level and either rework your patches or provide
446 If there are no responses to your posting, wait a few days and try
451   - expect your patch to be accepted without question
458 You have to be cooperative, and willing to adapt your idea to fit within
459 the kernel.  Or at least be willing to prove your idea is worth it.
463 It is normal that the answers to your first patch might simply be a list
464 of a dozen things you should correct.  This does **not** imply that your
466 personally.  Simply correct all issues raised against your patch and
477   Good things to say regarding your proposed changes:
513 recommended that you check your emails to make sure they make sense in
517 Break up your changes
523 the exact opposite of what companies are used to doing.  Your proposal
527 as a dumping ground for your feature.  However, don't send 50 emails at
528 one time to a mailing list, your patch series should be smaller than
533 1) Small patches increase the likelihood that your patches will be
563 solution and working together with the community and discussing your
565 get feedback to improve your work, but also keep your changes in small
566 chunks that they may get already accepted, even when your whole task is
573 Justify your change
576 Along with breaking up your patches, it is very important for you to let
581 Document your change
584 When sending in your patches, pay special attention to what you say in
585 the text in your email.  This information will become the ChangeLog