Managing another PostgreSQL Commitfest

I have written about managing a PostgreSQL commitfest before.

During the PostgreSQL 13 development cycle, I did it again. This time I used a different strategy, mostly because I felt that there was excessive accumulation of very old patches that had received insufficient attention. So apart from bugfixes (which are always special cases), I focused on patches that had been sitting in the queue for longer.

One thing I noticed is that some patches had not been updated per feedback, or per bit-rotting, even after repeated prodding from previous commitfest managers. They get moved from one commitfest to another with no other activity. Some of those are from people who have moved on from PostgreSQL development; others might be abandoned projects. In my opinion, there is no point in keeping them around if nothing is happening, so I closed those and provided a list, so that others can have a look and take ownership if they so desire. (A followup post contains some more).  My hope is that if anybody is interested in those features, they will pick up the patches and re-submit after addressing any feedback and bit-rot.

Another thing that’s becoming common is that many patches linger with little review — or sometimes even with substantial review they never get to the point where a committer picks them up. In some of those cases, my approach was to prod specific people that I thought could help with the review; in other cases, I just reviewed the patches myself. Sometimes, simply asking a question seems to have been enough to get others involved in the discussion, so even if one’s direct contribution is small, it has a useful larger effect.

I also signed up as a reviewer/committer for a few patches myself. I was moderately successful at that, ending with 24 commits and 10 commitfest-entries marked committed … or about 25% of the total number of commitfest entries committed. Not bad, eh?

In my closure report email, I posted this table:

One thing worth noting is how “returned with feedback” stayed pretty low the whole time and only jumped up at the very end, and by a largish count. An exercise that I suggest future CFMs doing is to healthily close inactive, bit-rot patches at the end of their mandate, instead of moving such patches to next commitfest. The latter operation should be reserved for patches that have been active during the CF, or those that still apply, or those that have been waiting for the authors only recently.  The other thing worth noting is the number of patches committed … or rather how slowly it climbed up.  Some committers were distracted by helping with Postgres 12 getting released; others were very active in patches that were not part of the commitfest. I expect that several committers will be paying more attention next time, and then we will see some actual progress.

Thomas Munro’s commitfest bot is an invaluable tool; patch authors should pay more attention to that. It would be much better to have that service integrated into our community commitfest infrastructure; I think that just requires some round tuits.

Some things that I would have liked to have:

• an updated pg_dump of the commitfest data, for local querying.
• I did obtain dumps weekly by asking the right person, and wrote some crude queries. We could provide the results of (improved versions of) such queries as reports in the apps, perhaps.
• Some improved filtering in the commitfest app would be welcome, too.
• The act of moving patches en masse to next CF could be better automated.

All in all, this was a very satisfying month and I hope it was valuable for PostgreSQL development. I am thankful that 2ndQuadrant gave me the opportunity to spend the month doing this … but even so, I look forward to returning to my regular duties.