Re: reducing the overhead of frequent table locks - now, with WIP patch

On Thu, Jun 9, 2011 at 2:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Jun 9, 2011 at 5:09 AM, Simon Riggs <simon(at)2ndquadrant(dot)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