Thursday, August 1, 2013

9.4 Commitfest 1 Wrap-up

The first CommitFest of the 9.4 development cycle involved an unprecedented number of patch submissions.  As of today, 9.4CF1 is still open because of one patch which apparently only Tom Lane can commit.  However, everything else out of a brutal commitfest has been done, and it's 16 days after the CF was supposed to finish, so I think I can write the wrap-up now.

First, let's talk numbers: this CF started with 106 patches, peaked at 108 patches, and finished with 102 patches (6 were moved to September).  This is over 50% more patches than we've had for the first CommitFest of the annual development cycle and more patches than we've had in any single CF before. Last year, CF1 only involved 59 patches.  So if you are a committer and you feel exhausted, that's why.  Some graphs:

As you can see, this year is a jump forward in the number of patches being submitted to the first commitfest, and if it's representative of the rest of the year, we're all going to spend a lot more time reviewing patches.

Why so many patches?  Well, I can think of a few reasons:
  • contributions from the staffs of SalesForce and Huawei
  • beginning of 2ndQuadrant's work on streaming logical replication
  • a bunch of regression test patches
  • some new major contributors, including one from Google Summer of Code
  • more people submitting WIP patches to get spec feedback
All of the above are unquestionably good things, and not anything we want to deter, so we need to find ways to shoulder the load.  On the other hand, I'm not going to pay much attention to anyone who tells me we're "making things difficult for submitters".

So what did we get out of all this patch activity?  Some highlight features:
  • new pgbench options
  • improvements in compression of BLOBs and large rows
  • a bunch more regression tests
  • create background workers at runtime
  • FILTER option for aggregates
  • Part 1 of streaming logical replication
  • WITH ORDINALITY to supply "row numbers" for set-returning functions
All in all, 49 patches were committed (I'm expecting the remaining pending patch to make a round 50).  However, 46 were sent back and an additional 6 were moved to the September CommitFest, so we need to plan for that one to be busy too.

So, what are we going to do to handle more patches?  I have some thoughts on that in my next blog post ...


  1. Hi,

    A nice summary.

    Btw, in the previous CommitFest, what will be happened with patches marked as "Returned with Feedback"?

    Will it be moved to next CommitFest?

    If I'm not mistaken, this 9.4CF1, contains valuable tsearch2 optimization from A. Korotkov.

    1. The author of a "Returned with Feedback" patch is encouraged to update their submission and resubmit it for the next CommitFest. They don't get moved forward automatically.

    2. We don't move most patches automatically to the next commitfest for two reasons: (1) generally the author needs to make changes to the patch somehow before the next CF, and (2) the author needs to *be available* during the next CF. For any individual author either of those things could not happen. Maybe they need to skip the next CF and move to the succeeding one. Maybe they're now rethinking their whole approach.

      The ones I moved were moved because they were already near commit, and were only on hold because people were still discussing spec items.