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
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 |