Re: Last gasp - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Last gasp
Date
Msg-id CA+U5nMJ3UC64GwucxyA2LSPx0ou8+jmL_RX+VehnFMhc3mu-QQ@mail.gmail.com
Whole thread Raw
In response to Re: Last gasp  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Apr 15, 2012 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Fix PL/Python metadata when there is no result
Next
From: Noah Misch
Date:
Subject: Re: how to create a non-inherited CHECK constraint in CREATE TABLE