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

On Wed, Jun 8, 2011 at 6:43 PM, Joshua Berkus <josh(at)agliodbs(dot)com> wrote:
> 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.

You're right this is a non-argument.

I am not continuing this debate using the above point. I am merely
correcting people's assertions about what I think, which is a little
tiresome for all of us and it would be much better if people didn't
foolishly put words in my mouth, as multiple people have done on this
thread.

I'm also quite happy with the feature set for 9.1.

>> 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.

I claimed they delivered half-finished features. You clearly agree
with me on that. I'm not sure which part you see as BS?

> 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.

Yes, I've also experienced totally marketing-driven software
development, and that's why I'm *here*. I've spoken at length about
how good our process is and have considerable respect for it and the
people that have made it work. I am not advocating any changes to it
at all, especially not to the model used by MYSQL AB.

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. I was one of a number of developers making that point at the
developer meeting and I would say I was part of the majority view.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services