Xaprb

MySQL 5.4 was released this week at the MySQL conference, and billed as the “community release.” This seemed odd to some of us, and I heard lots of comment on it in the hallways. After all, the release was a surprise; the community didn’t know it was happening.

A source from within Sun, who is familiar with the details and wishes to remain anonymous, told me the story behind the release. I want to say that after this conversation, I fully support the release of 5.4 and I want to praise it generously. It is a great step in lots of right directions! It’s good for everyone. The secrecy was a necessary strategy.

The details must remain a secret, but perhaps someday it’ll be known.

Thank you Sun!

Some unsettling things happened in MySQL in the past week or so.

New storage engine not mentioned in the changelog

There’s a bit of a storm brewing over at the MySQL Performance Blog, where Vadim reports discovering a new storage engine added without mention in the 5.1.33 changelog. This is in defiance of the policy of not making changes in a production release. And it certainly belongs in the changelog — but there is no sign that anyone will remedy this problem.

Arjen Lentz, who is ex-MySQL and was Employee #25, reported a bug on the licensing of this storage engine. To my eyes, the engine’s license does not look right to include in a GPL database. Arjen agrees.

But the bug report he entered is now marked secret. This is a great way to draw attention to it. Now I’m wondering: does this have something to do with the MySQL 5.1 community/enterprise split that was announced last year but hasn’t been implemented yet? Maybe they’re going to unwrap something at the conference this year, like they did last year? I hope not. That was unpleasant and should not be repeated.

Three private bug reports in the changelog

I noticed one private bug report in the 5.1.33 changelog itself. I wrote to the author of the 5.1.33 release announcement about it 3 days ago, but have received no response.

So after seeing that Arjen’s report was private, I just clicked through all the bugs mentioned in the 5.1.33 changelog and found two more that I’m barred from viewing. Here are all three:

 * The MD5 algorithm now uses the Xfree implementation.
   (Bug#42434: http://bugs.mysql.com/42434)
 * Use of USE INDEX hints could cause EXPLAIN EXTENDED to crash.
   (Bug#43354: http://bugs.mysql.com/43354)
 * MySQL 5.1 crashed with index merge algorithm and merge tables.
   A query in the MyISAM merge table caused a crash if the index
   merge algorithm was being used.
   (Bug#40675: http://bugs.mysql.com/40675)

What reason can there be to make those private? I would like to encourage MySQL to discontinue this practice except when vitally necessary to protect client data. In my opinion, when someone submits a private bug to a software project that wants to be open-source, there should be a strong push-back. Private client data can go into a private comment; the whole bug report doesn’t have to be sealed off. Consider the harm caused by private bug reports: it’s now much harder for me to see what changeset fixed the bug. I can’t see any of the discussion about it. I can’t make any decisions about whether it affects me or clients.

I am concerned about the lack of openness and transparency in all of these issues, and others have told me that they are too.

The conference that many of us just went to is called the MySQL Conference and Expo, but a lot of people don’t call it that. They call it by the name it had in 2006 and earlier: MySQL User’s Conference. In fact, some people say (or blog) that they dislike the new name and they’re going to call it the old name, because [... insert reason here...].

I call it by the new name that some people dislike so much. Why? Because it is a conference and expo, not a user’s conference. There’s no reason to pretend otherwise. The conference is organized and owned by MySQL, not the users. It isn’t a community event. It isn’t about you and me first and foremost. It’s about a company trying to successfully build a business, and other companies paying to be sponsors and show their products in the expo hall. Times have changed.

I’m not saying any of this is bad. Being successful in business is a good thing, and having sponsors and partners is fine too. I’m just pointing out that trying to make it be a user’s conference, just by calling it one, isn’t going to work.

If community members want a community conference, we’ll have to make one. MySQL/Sun cannot do this for us, because then it wouldn’t be a community conference.

There’s a simple test of whether people want this: if it happens, then the community wanted it badly enough to do something about it.

The PostgreSQL East 2008 conference I went to a few weeks ago was a great example of how this works. And the attendance fee was $75, not thousands. A conference doesn’t have to be expensive.

Who wants a conference by, for, and of the community?