From Fedora Project Wiki

Revision as of 21:25, 7 May 2015 by Labbott (talk | contribs) (Created page with "Sometimes you may be asked to submit your patch upstream directly. Generally this is because the patch does not meet [[KernelDriverPolicy | the requirements for being carried ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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.