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

Simon,

> The point I have made is that I disagree with a feature freeze date
> fixed ahead of time without regard to the content of the forthcoming
> release. I've not said I disagree with feature freezes altogether,
> which would be utterly ridiculous. Fixed dates are IMHO much less
> important than a sensible and useful feature set for our users.

This is such a non-argument it's silly. We have so many new major features for 9.1 that I'm having trouble writing sensible press releases which don't sound like a laundry list.

> MySQL
> repeatedly delivered releases with half-finished features and earned
> much disrespect. We have never done that previously and I am against
> doing so in the future.

This is also total BS. I worked on the MySQL team. Before Sun/Oracle, MySQL specifically had feature-driven releases, where Marketing decided what features 5.0, 5.1 and 5.2 would have. They also accepted new features during beta if Marketing liked them enough. This resulted in the 5.1 release being *three years late*, and 5.3 being cancelled altogether. And let's talk about the legendary instability of 5.0, because they decided that they couldn't cancel partitioning and stored procedures, whether they were ready for prime time or not and because they kept changing the API during beta.

MySQL never had time-based releases before Oracle took them over. And Oracle has been having feature-free releases because they're trying to work through MySQL's list of thousands of unfixed bugs which dates back to 2003.

An argument for feature-driven releases is in fact an argument for the MySQL AB development model. And that's not a company I want to emulate.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
San Francisco