Why MySQL 5.1 Is Not GA Yet, and How You Can Help

Posted in: MySQL, Technical Track

Yesterday I had a good conversation with Monty Widenius (a MySQL founder) about MySQL 5.1. Specifically, about the fact that MySQL 5.1 is not a GA (generally available) release.

My impression, which was wrong, was that it was difficult getting critical mass to download 5.1 and use it simply because it was not a GA release yet. I thought the paradox of needing to have a certain amount of usage before release was the barrier.

That’s not the case at all.

The problem is that bugs in MySQL 5.1 are not being fixed. Part of the way a bug is deemed critical enough to be worked on is how many people are running into the bug.

I am of the ilk that “me too” types of posts are somewhat frustrating. When I find a bug, I try to find it on http://bugs.mysql.com. If it is there, I add any relevant information. However, I do not simply write “this bug affects me too” because I am annoyed by “me too” type posts.

However, Monty explained to me that if we ever want MySQL 5.1 to become GA, we need to review the bug list for MySQL 5.1 and for any bugs that you want fixed, put a “me too” in there. Something like “I would use MySQL 5.1 if this bug were fixed” is sufficient.


Interested in working with Sheeri? Schedule a tech call.

10 Comments. Leave new

Colin Charles Agenda » Blog Archive » “Me too” comments in bug systems
July 22, 2008 6:58 pm

[…] don’t know about “me too” types of bug replies, but before everyone goes to the bug database and starts saying “me too”, “this […]


Bugs are found when software is used in “interesting” environments.
MySQL 5.1 has seen plenty of downloads I’m sure.
The issue is indeed the feedback cycle not functioning. If someone finds a problem, reports it, but it doesn’t see action, then this causes a negative chain reaction for this person’s participation.
They won’t bother filing more problem reports, they won’t bother downloading newer 5.1 versions, and they might not even bother continuing to use 5.1 at all if the problems are hindering their work.


Unfortunately you do, on some level, run into the same paradox, albeit indirectly. Because fewer people are using the non-GA version, you have fewer people to notice/report these bugs. This in addition to having people like you who tend to avoid echoing existing reports.


That’s an interesting way of doing things. Shouldn’t the internal team be reviewing the severity of the bug and fixing it based on that? I just can’t understand the way MySqlAB (and now Sun) works sometimes…

Tony Marston
July 23, 2008 3:18 am

Wouldn’t it be easier to have a counter that people could increment simply by pressing a button that says “This bug affects me too”? Seeing a counter with a high value would be better than having to trawl through all those “me too” posts.


Which is completely crazy. A bug exists in a bug tracker to be fixed, not to be fixed once it reaches enough “me toos!”

I wonder about the quality of Linux (the kernel) if a similar prioritisation model was adopted…

Sheeri Cabral
July 23, 2008 5:08 pm

Mike and James — I think the issue is that the internal team can’t get a good sense of priority of which bugs to fix unless there’s some way to see whether it’s affecting one person or many.

Tony — yes, it would be much easier, but there isn’t currently one there, and we’d like 5.1 released as soon as possible.

Michael Denney
July 24, 2008 9:10 am

If the “me too” model is not working, at the least they should just start fixing bugs. Just showing that things are being fixed in the bug tracker alone could go a long way for inspiring confidence in MySQL 5.1, increasing the usage rates, and then as a result increasing the bug reports.

Fixing bugs based on the number of reports received for a bug would work, if a large amount of users were using the system, if you only have a few users you’re only going to get a few bug reports, even if the bug is major.

Jonathan Mark
April 9, 2009 12:15 pm

Basing a bug on, “me too” system is kind of silly and so I agree with you. I also agree with the person that says the team may not know which bugs are a priority but atill shouldn’t you try to make it bug free regardless of whether it’s possible or not. I’m saying shouldn’t their goals be remove all bugs and even if they have a problem ranking priority they should have a general idea of the more crtiical ones.


Very good article. I certainly appreciate this site.
Stick with it!


Leave a Reply

Your email address will not be published. Required fields are marked *