I have heard repeated concerns about the commitfest process in the past few months. The fact we have been in a continual commitfest since August also is concerning.
I think we are reaching the limits on how much we can do with our existing commitfest structure, and it might be time to consider changes. While the commitfest process hasn't changed much and was very successful in the first few years, a few things have changed externally: 1 more new developers involved in contributing small patches 2 more full-time developers creating big patches 3 increased time demands on experienced Postgres developers These changes are all driven by increased Postgres popularity. In an ideal world, as 1 and 2 increase, the time experienced developers have to work on commitfest items would also increase, but the opposite has happened. Many of our most experienced developers (3) hold responsible positions in their organizations which demand their time. You would think that more full-time developers (2) would help with the commitfest, but often their paid work is in a specific subsystem of Postgres, preventing them from effectively helping with other complex patches. We have always known that we can create novice developers faster than experienced ones, but it seems this difference is accelerating. A good example is the UPSERT patch, which, while receiving extensive feedback on the user interface and syntax, has not had a full review, though it has been posted for several months. It seems like a good time to consider options for restructuring our process. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers