Re: Last gasp

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Last gasp
Date: 2012-04-15 19:13:23
Message-ID: CA+U5nMJ3UC64GwucxyA2LSPx0ou8+jmL_RX+VehnFMhc3mu-QQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 15, 2012 at 4:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I think this is a rather unfair summary of the history.  It was clear
> very early in the CF that people thought Command Triggers had major
> design problems, and Dimitri was doing significant rewrites to try to
> fix that.  Anyone who did not think that patch was at serious risk of
> not being committed simply wasn't paying attention.

Fair comment, since I was definitely not paying attention.

My I-Want-a-Pony idea is some kind of rating system that allows us all
to judge patches in terms of importance/popularity, complexity and
maturity. I guess a Balanced Scorecard for the development process. So
we can all see whats going on. We already do this when we speak to
each other in hushed tones that so-and-so a patch looks unlikely etc..
If we could do that more openly it would help.

> The more general point here is that the last fest of a release cycle
> is the worst possible time to be landing big, destabilizing patches.
> I think we ought to be conservative at this stage of the cycle, in
> hopes of keeping beta phase short and predictable.

There is a definite selection effect that means the bigger the patch
the more likely it is to land later in the release cycle, regrettably.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2012-04-15 20:15:35 Re: how to create a non-inherited CHECK constraint in CREATE TABLE
Previous Message Peter Eisentraut 2012-04-15 17:27:06 Re: Fix PL/Python metadata when there is no result