On Wed, Jun 7, 2017 at 5:47 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> It has become clear that the scope of problems being found now
> exceed what I can be sure of being able to fix in time to make for a
> stable release, in spite of the heroic efforts Thomas has been
> putting in. I had hoped to get this into the first or second CF of
> this release, same with the release before, and same with the
> release before that. At least landing it in the final CF drew the
> level of review and testing needed to polish it, but it's far from
> ideal timing (or procedure). I can revert from v10 and deal with
> all of this for the first CF of some future release, but if someone
> feels they can deal with it in v10 I'll stand back and offer what
> help I can.
I really don't know what to make of this. I can't ever remember a
committer taking this attitude before. Aside from committing one
patch that Thomas submitted shortly after the original commit, you
haven't been willing to write, review, or commit a single line of
code. The problem doesn't seem to be that the amount of effort is any
more than it would be for any other feature this size; it's in better
shape than some. The problem appears to be, rather, that the scope of
problems you were willing to try to fix in a timely fashion was
basically zero, which isn't very realistic for a patch of this size no
matter who has reviewed it or in what level of detail.
We don't have a lot of formal documentation around the
responsibilities of PostgreSQL committers, but I think one that is
pretty clearly acknowledged is "you are responsible for what you
commit". If you're not willing to be responsible for your own
patches, turn in your commit bit. Then, when you submit a patch,
it'll either not get committed, or it'll be the responsibility of
whoever does.
I freely admit I encouraged you to commit this. I did not imagine
that would be followed immediately by abdicating all responsibility
for it. My mistake, I guess.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
