Upstreaming drm patches


Sending the patch

  • Add the upstream repo as a remote in your git tree
    • For kernel patches, consult the MAINTAINERS file or scripts/ to find the remote git tree location
    • For libdrm patches, the tree is located at git://
    ; git remote add -f upstream <remote_addr>
    ; git fetch upstream
    • Create a new branch which tracks upstream
      • For kernel, the branch will depend on how the maintainer has setup their tree. Ask on IRC if you're unsure.
      • For libdrm, use the master branch
    ; git branch -t for_upstream upstream/<upstream_branch>
    • Apply the patch to your for_upstream branch (resolving any conflicts) and test the patch still works
    • Generate a patch file for upstream, it will be saved as 0001-<my-commit-subject>.patch
      • For libdrm, add --subject-prefix 'PATCH libdrm' to the command
      • If you have not added a Signed-off-by: line to your commit message, add --signoff to the command
    ; git format-patch <optional parameters> HEAD^..
    • Open the patch file and strip out all of the Google-specific kruft (Bug, Test, Change-Id, etc). Once again, ensure you have a Signed-off-by: line in the commit message
      • If this is a v2/v3/vN patch, add vX to the subject after PATCH (ie: [PATCH vX] my commit subject)
    • Send the patch to the list
      • For kernel patches:
        • Run the patch through scripts/ to ensure it conforms with kernel style guide
        • Run the patch through scripts/ to generate a list of people/lists who should be cc'd
      • Make sure you cc anyone who provided you with a downstream review, as well as people who can help with upstream review (seanpaul@, marcheu@, etc)
        • Use the --cc argument to git send-email
      • To reply to an email with a patch (ex: after code review), add the --in-reply-to=<Message-Id> argument. You can get <Message-Id> from mail headers
      • If you want ONE MORE chance to ensure that everything is right for the patch, add the --annotate flag to send-email, it'll let you review the message before sending
      • If this is a series of patches, add a cover letter to explain the series with the --cover-letter 
    ; git send-email