Xaprb

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.