Zack Urlocker says MySQL 5.1 has zero bugs. He may have been misquoted, or quoted out of context, but there it is. I’ll quote enough of it that you can’t take it out of context twice:
Mickos also said MySQL 5.1 has upgraded its reliability and ease of use over 2005’s v5.0.
“Now we can admit it, but this version is much improved over 5.0, which we weren’t totally happy with,” Mickos confided.
He reported that more than 1,300 bugs (997 in 2007, 386 so far in 2008) have been fixed in v5.1, and that, according to standard DBT2 benchmarks, the performance of v5.1 is 10 to 15 percent better than the previous version.
“This version now has zero bugs,” Urlocker told eWEEK.
You can check for yourself at the MySQL bug statistics page.
Of course it’s not true. But what did Zack really say, I wonder?
Technorati Tags:bugs, innodb, Marten Mickos, mysql, Zach Urlocker
Baron,
There is really 0 bugs.
In MySQL GUI Common: Docs:, Server: Memory:, Server: XML: and some other categories.
If its true, then it would be has “0 known bugs”, as complex software always has bugs.
I think he meant zarro boogs:
“The response “zarro boogs” is intended as a buggy statement itself, implying that even when no bugs have been identified, software is still likely to contain bugs that haven’t been identified yet.”
That’s easy - of course there’re “zero bugs”. Depends on the criteria.
Looking at the bugdb everybody can see there’re tons of bugs. There’s no way to fix them all in any reasonable time frame. What could a management do ? Categorize them. These are low-impact, for these there’s a trivial workaround, these are more an annoyance than a real bug. What’s left ? Okay, these are too difficult to fix, we cannot risk doing major changes in 5.0 or 5.1, these affect only a handful of users, these behave as documented even if it’s confusing, these behave as intended we should just document this weird behavior. What else ? Yeah, unfortunately this is a crash caused by a simple query, looks like we have to fix it. And in this one ORDER BY doesn’t seem to work, cannot declare its “not a bug”. Now let’s tag all bugs that managed to stay “real bugs” no matter how hard we tried to avoid fixing them.
And when all tagged bugs are fixed - one can proudly say “MySQL has zero bugs”. Indeed.
Make no mistake - categorizing and prioritizing bugs is the right way to do. And fixing crashing bugs or non-working ORDER BY before, say, duplicate warning for out-of-range variable assignment is correct. And I’ll be the first to declare a very weird behavior “not a bug” if it’s documented or at least intended (and I did - check bugdb :).
But saying that because of this “MySQL has zero bugs” is ridiculous.
Sergei, I can’t tell whether you’re defending, explaining, or laughing at the article I referred to. Or maybe something else?
All at once.
Explaining how Zack came to his “zero bugs” result. Defending the practice of giving different priorities to different bugs. Laughing at the absurd “zero bugs” conclusion coming from taking this practice to an extreme.
Sergei,
So your classification of bug recalls me old Chinese taxonomy
Animals are divided into:
# those that belong to the Emperor,
# embalmed ones,
# those that are trained,
# suckling pigs,
# mermaids,
# fabulous ones,
# stray dogs,
# those included in the present classification,
# those that tremble as if they were mad,
# innumerable ones,
# those drawn with a very fine camelhair brush,
# others,
# those that have just broken a flower vase,
# those that from a long way off look like flies
(http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge’s_Taxonomy)
The original article is such utter word salad anyway. “released to general availability a near-final release candidate of Version 5.1″ What? Is it GA, or is it just a GA RC? Is the author perhaps the winner of a beauty pageant?