Commitfest problems

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +