1. Discuss the patch online until it feels ready to merge.

  2. Make sure the patch comes with tests if applicable.

  3. Update the git-svn repository

    git svn fetch
    git svn rebase
    
  4. Fetch the patch and apply it to the git-svn repository.

    For a github pull request https://github.com/ocaml/ocaml/pull/{N} I do

    wget https://github.com/ocaml/ocaml/pull/{N}.patch
    git am -3 {N}.patch
    

    For an arbitrary patch foo.patch on my filesystem,

    git apply --reject foo.patch
    
  5. Rebase the patch series

  6. Write a Changelog entry:

    This changelog work can be amended to the user's patch (if it's just one patch) or as a separate commit (if it's a patch series and no particular commit feels best suited to receive the Changelog entry.

    (Do not under-estimate the importance of a good changelog. Users do read the release notes, and things forgotten from the changelog will cause pain or regrets down the line.)

  7. Edit the patch series' commit messages to preserve author information

    SVN will erase the committer name at merge time. My convention to retain authorship information is to use the following format for commit messages:

    {one-liner header description (with issue number if possible)}
    {blank line}
    ({author name})
    {blank line}
    {one or several paragraphs of explanation if needed}
    

    The {author name} can be just the full name of the author, or sometimes "(Patch by {full name})". If an author is known only by his mantis or github pseudonym, I use "{pseudonym}" or "user '{pseudonym}'" as full name.

    (git-svn has an option --add-author-from that inserts a credit line at the same place in the commit message, using a different format. I found it inconvient however to use it reliably when merging patch series, as there are often commit of mine in the mix that don't need this extra information, so hand-editing each commit message is my preferred method.)

  8. make world.opt and check that the testsuite still passes

    make tests
    

    If a specific test testsuite/tests/{foo} was broken by a previous iteration, it can be tested in isolation with

    cd testsuite
    make one DIR=tests/foo
    

    To understand a failure, go to testsuite/tests/foo and compare the .result files to their corresponding .reference files.

  9. Commit the patch series

    git svn dcommit
    
  10. If you are subscribed to the CI, watch for angry emails from ci.inria.fr telling you that you broke stuff (typically: on 32 bits systems, or under MSVC).