• Outreachyfirstpatch

Hooray! Thanks for your interest in working on the Linux kernel. The next step is to [:OPWApply:apply] to OPW, and use this tutorial to create your first patch to the Linux kernel.

Intro

If you run into any issues with this tutorial, please ask questions on the #kernel-opw IRC channel on irc.oftc.net, or on the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list].

Anchor(kernel-setup-done)

Contribution Instructions

PLEASE NOTE: DO NOT SEND YOUR FIRST PATCH TO THE MAIN LINUX MAILING LISTS!

Instead, send your patch to the [https://groups.google.com/forum/#!forum/opw-kernel opw-kernel mailing list].

Include(FirstKernelPatch)

Resending patches

If you find a mistake in your initial patch submission, and you need to correct it, make sure to version your new patch as described below.

If your patch has not been responded to within three business days (not including weekend days), the mentors may have missed it, and you may want to resend it. Make sure to use RESEND in the subject line if the patch itself has not been changed (meaning no changes in the patch description or body). You can use the --subject-prefix argument to git format-patch to add RESEND, by running

git format-patch --subject-prefix="RESEND PATCH"

That command will create an email you can send with mutt (or your approved mail client) that will have a subject that looks like:

[RESEND PATCH] Foo: Fix these things

If your patch hasn't been responded to within a week, ping a mentor (or sarahsharp) on the IRC channel. Do not ping mentors immediately after sending patches. We know you're excited/worried about submitting your first patch, but mentors need to take time to properly respond and review patches.

Tips

Last round's criteria for selecting applicants was:

1. Whether applicants moved from simple patches to more complex patches (code refactoring, bug fixes, or sparse cleanups).
2. Whether applicants created simple patches for their first or second project choices.
3. Whether patches were consistently correct (i.e. no checkpatch errors or build warnings added).
4. How many patches were accepted.
5. Strength of C programming experience, as judged by patches.
6. Communication style over email and IRC.
7. How responsive applicants were to feedback.
8. Whether applicants were self-learners.
9. Whether mentor and applicant timezone differences would work.
10. Applicants' time commitments over the internship period.

Make sure to submit patches early in the application period. Build up your patch portfolio by sending a few larger (3-6 patch) patchsets, then take on more complex patches for Sparse, Coccinelle, or code refactoring. Most importantly, try to create patches for the projects you're most interested in, especially focusing on any small TODO items that mentors post.

Finally, please make sure you have more than one kernel project listed in your application, so that if your top choice is taken, you can still be considered for another project.