Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers

From Dave Page
Subject Re: reducing the overhead of frequent table locks - now, with WIP patch
Date
Msg-id BANLkTi=6Xqb8nN33zntyzcFN6dgRSRbtEQ@mail.gmail.com
Whole thread Raw
In response to Re: reducing the overhead of frequent table locks - now, with WIP patch  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reducing the overhead of frequent table locks - now, with WIP patch
List pgsql-hackers
On Thu, Jun 9, 2011 at 2:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> I have asked that we maintain the Reasonableness we have always had
>> about how the feature freeze date was applied. An example of such
>> reasonableness is that if a feature is a few days late and it is
>> important, then it would still go into the release. An example of
>> unreasonableness would be to close the feature freeze on a
>> predetermined date, without regard to the state of the feature set in
>> the release. To date, we have always been reasonable and I don't want
>> to change the process in the way Robert has suggested we should
>> change.
>
> Now you're putting words in my mouth.  I wouldn't want to put out a
> release without a good feature set, either, but we don't have that
> problem.  Getting them out on a fairly regular schedule without a
> really long feature freeze has traditionally been a bit harder.  I
> believe that over the last few releases we've actually gotten better
> at integrating larger patches while also sticking closer to the
> schedule; and I'd like to continue to get better at both of those
> things.  I don't advocate blind adherence to the feature freeze date
> either, but I do prefer to see deviations measured in days or at most
> weeks rather than months; and I have a lot more sympathy for the
> "patch submitted and no one got around to reviewing it" situation than
> I do for the "patch just plain got here late" case.

Can we make this the last post on this topic please?

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Next
From: Pavan Deolasee
Date:
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch