Archive for the ‘Transparency’ tag
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.