How did micro-slow logging get into 5.1? Rumor is it was rejected, and then Monty decided to subvert that decision and included it as part of something else. If not for Monty’s rebellion, it still wouldn’t be there. That is, if the rumor is true. I haven’t bothered to check the commit history.

I’m really sympathetic to your comments in this thread. If I were in your place, I believe I’d feel the same way. I’m sorry that the upper-level management’s decisions are causing this backlash that gets directed a little indiscriminately. But seriously, from an outsider’s point of view, nobody says “Sun’s management doesn’t care, although I’m sure there are support engineers behind there somewhere who do.” For better or for worse, from the outside it all looks like one big Sun, and there are no unsung heroes in sight. This is not MY point of view, but it’s certainly what I think the general public sees.

@Sinisa,

“Regarding scalability patches, yes, we have a number of customers using those patches. We can, however, solve most of the problems without them,”

Eh…. tell that to your customers who come to us (Percona) after getting completely frustrated with Sun/MySQL and giving up. It’s not that uncommon for me to answer the phone and hear someone say “I hope you guys can help us. We’ve been working with Sun on this for three weeks and we’ve gotten nowhere. They keep telling us there is no problem.” And then we sometimes need to make a patch to solve it. You should realize that unhappy customers sometimes simply walk away quietly and get help elsewhere.

I’ve written nearly the entire stack of Spinn3r other than the kernel and the database so it’s not out of the question :)

Generally, we at Innobase/Oracle have been watching the community activity with interest. We are familiar with some the proposed patches and have been evaluating them for possible inclusion in InnoDB. To echo Jeffrey’s comments, a great deal of testing is required to validate performance-related changes, as these involve the most critical elements of a database or storage engine.

We’ve been working closely with Google regarding one such performance-oriented patch, for example. We have identified some issues and subsequently resolved them, but there is still more to do. We haven’t as yet seen the results of Sun/MySQL’s lab testing (though we’d love to!). We also note that the publicly visible testing we’ve seen to date represent different and fairly narrow workloads and often demonstrate performance with more than one independent patch applied. While community feedback is helpful, testing in a scientific manner is essential.

Several things must be considered in determining whether or not a community contribution can be incorporated into InnoDB. First, we must have complete confidence in the technical correctness and reliability of the code. We want to maintain the reliability of InnoDB, and ensure that the proposed changes have a positive impact on a wide range of workloads. Second, we must believe that the approach taken in a proposed patch is the best way to address a problem or need. We may have plans or an idea for more comprehensive or better architected functionality. Last and not least, since we license InnoDB commercially, we must have complete control over intellectual property. Software contributed under the GPL cannot be licensed commercially, although code covered by the BSD license can be incorporated in a commercially-licensed product. We need complete confidence of the provenance of contributed code.

For a variety of reasons, we can’t evaluate every patch that appears in the community, and we can’t publicly predict whether or when a particular patch may be incorporated in InnoDB. You should know, however, that we are not opposed to accepting community contributions under the proper circumstances.

Everyone I’ve met at MySQL from the developers on up to senior management have been nice people and clearly cared a LOT about MySQL.

The blame doesn’t lie there… there’s just some sort of emergent property happening where they’re continually adding features while risking the reliability of the product.

I do respect MySQL Support engineers and do respect MySQL Software engineers, I’ve never had thought to blame them. I can’t recall anyone who did.

But something wrong is happening, and Kevin is pointing on in this post. I believe this something wrong is coming not from MySQL Support & Development teams.

Not adding features to a GA version is a good thing, stability is a requirement and at least for me MySQL 5.0 has been rock solid and working for years.

As you said, the silliness lies in the early beta stadium of 5.1, so that new feature all go into the 6.0 tree and there is still uncertainity how long it will take to reach GA stage. I’d rather have less features in one release.

Regarding Oracle, they seem to be finally picking up pace which is strongly related to 5.1 and I hope to see more improvements now that the storage engines can be seperated from the core. As I stated earlier this was the most exciting thing about 5.1 for me as storage engine vendors don’t need to wait for their code to be included in the main product. Just look at what the NDB guys accomplished.

Also I think there is a line between insult and criticism, I don’t think that Monty (in his blog entry, he definitely doesn’t blame the developers!) and Kevin crossed it.
This one however crossed the line:
http://trainedmonkey.com/2008/12/3/an_observer_of_his_own_legacy

Most of the criticism is directed at the release schedule and priorities and general community policy, not at the quality of the work. So the question is, who is really to blame?

I am still waiting for comments from Sun/MySQL executives regarding the criticism of 5.1 however.

Last but not least, who am I to complain? After all it’s free ;)