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

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.

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