Sunday, July 19, 2009

Crashing bugs

What does it mean to release a server with no known crashing bugs? I don't know. A lot of this depends on your perspective. Perhaps old releases of MySQL were done with no known crashing bugs, but this means that testing for current releases is much more rigorous. If you don't believe me then read some of the bug updates from Shane and others to understand how good they are at testing it.

I judge quality by whether I can depend on the code in production. Both 4.0 and 5.0 have been stable in production for me and both have had crashing bugs. I am sure that MySQL 5.0 releases have had more known bugs than 4.0 releases as 5.0 has more features, a larger community testing it and is run on much larger hardware (more RAM, more disks, multicore, more load). Note that my perception of 5.0 is based on using it with many features disabled including query cache, subqueries, stored procedures, triggers and views.

The quality metric that I am interested in is the number of major releases for a feature to become stable in production and feature complete. I don't mind when this number if more than 1 as long as I can disable the feature. But this number should never exceed 2.

2 comments:

  1. Releasing with no known crashing bugs mean that simply checking the bug tracker (or a mailing list archive) is not enough to make you an hacker able to take down a production database.
    Sounds simple enough? ;)

    ReplyDelete
  2. @Anon -- are people exposing MySQL deployments to hackers? A mean-spirited insider is more likely to be able to exploit such a bug.

    ReplyDelete

 
Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.