< Kernel
Sometimes you may be asked to submit your patch upstream directly. Generally this is because the patch does not meet the requirements for being carried out of tree. This page is intended to help get the patch submitted and is written with the assumption you already have a set of changes or a reasonable idea of what those change are.
Getting Started
Kernel Newbies has a solid introduction on the basics of setting up your environment and a good guide overall. What follows are just some highlights.
Identifying where the patch needs to go
The kernel provides a script called get_maintainer.pl. This lists mailing lists and people to send the patch to.
$ scripts/get_maintainer.pl 0001-fix_a_bug.patch
Kernel Newbies once again has a good example of how this works. Be careful about adding people who aren't explicitly listed as maintainers even if get_maintainer.pl spits out their name.
Commit text
Each patch needs to have a description of what is being modified. Good commit text should indicate
- What is being changed
- Why is this change being made
- What are the user visible effects without this patch
The last point is especially important if the patch is fixing a crash. The first line of your commit text should indicate the subsystem and give a one sentence summary of the patch. If you don't know the subsystem, you can use 'git log' to see what past patches have done.
Example
a_driver: Fix queuing race condition The driver currently locks the queue on device insertion but doesn't lock the queue on device removal. This results in a race and an oops if there are outstanding items in the queue on removal. Fix this by locking properly on device removal. Signed-off-by: A. Kernel Developer <adeveloper@totallyrealaddress.com>
Double checking your patch
- Did you read the instructions in SubmittingPatches
- Are you sending to the right mailing lists?
- Do you have a Signed-off-by?
- Have you run checkpatch.pl and fixed any major errors?
- Are you sending your patch in the body of the e-mail and _NOT_ as an attachment?
Getting a response
Most people on the mailing list are responsive but patches can get lost in the shuffle. If you haven't gotten a response within a week, double check all the addresses and who you sent the patch to. If everything looks correct, you can try resending the same patch with a tag of [RESEND] in the subject line.
Once you get a response, you can follow the instructions at Kernel Newbies for responding and revising your patch set
Getting the patch into Fedora
Once the maintainer has accepted your patch, the patch will eventually make it into a Fedora release when the appropriate kernel is added. If you want to bring the patch in sooner, contact the Fedora kernel team.