Managing another PostgreSQL Commitfest

October 15, 2019

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:

Status week1 week2 week3 week4 final
Needs review 165 138 116 118 0
Waiting on Author 30 44 51 44 0
Ready for Committer 11 5 8 11 0
Returned with Feedback 1 4 5 5 28
Moved to next CF 2 4 4 4 191
Committed 14 23 32 34 42
Rejected 1 1 1 1 1
Withdrawn 4 9 11 11 12

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.

Share this

More Blogs

RAG app with Postgres and pgvector

Build a RAG app using Postgres and pgvector to enhance AI applications with improved data management, privacy, and efficient local LLM integration.
October 08, 2024

Mastering PostgreSQL in Kubernetes with CloudNativePG

Previewing EDB’s training session for PGConf.EU 2024, presented by our Kubernetes experts EDB is committed to advancing PostgreSQL by sharing our expertise and insights, especially as the landscape of database...
September 30, 2024

The Expanding World of AI and Postgres

It wasn’t long ago that AI was considered a niche topic of interest reserved for researchers and academics. But as AI/ML engineers with extensive research backgrounds entered the industry, AI...
September 25, 2024