Re: Explicit psqlrc - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Explicit psqlrc
Date
Msg-id AANLkTikX_TyGZcv_JgeviLf+8xEiPr41VOYOWtBbckxH@mail.gmail.com
Whole thread Raw
In response to Re: Explicit psqlrc  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Explicit psqlrc
List pgsql-hackers
On Tue, Jul 20, 2010 at 7:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> So focus your effort by leaving this alone until the end of the CF.
> Actively terminating things early doesn't help at all with the review
> work you mention above, but it looks good if we are measuring "cases
> resolved per day". Are we measuring that? If so, why? Who cares?

We don't formally measure that, but yeah, I definitely keep an eye on
it.  I've found that if you don't keep a sharp eye on that, you end up
not done with the CommitFest is supposed to be over.  I'd much rather
boot patches for reasonable justification throughout the CommitFest
than boot everything at the end whether there's a justification or
not.

> Closing early gains us nothing, though might close the door on useful
> work in progress.

IMHO, closing early LOSES us nothing.  People are free to work on
their patches whenever they'd like, and hopefully will.  But
pretending we're going to review them all no matter when they get
resubmitted just makes people grumpy when they find out that we're not
magical and can't.  A further point is that it's very difficult to
keep track of progress if the CF page reflects a whole bunch of
supposedly "Waiting on Author" patches that are really quite
thoroughly dead.

On the other hand, if this patch was really resubmitted already and I
missed it, as you suggested, that's a whole different situation.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Marc Cousin
Date:
Subject: Re: lock_timeout GUC patch - Review
Next
From: Simon Riggs
Date:
Subject: Re: Explicit psqlrc