October 21, 2014

Making bugs public – good job MySQL

If you have been MySQL User for many years you might remember the times when MySQL had “zero bugs policy”, this is when all known bugs really were fixed before release was made. To be honest at that time bugs were reported via bugs mailing list not via bugs database as they are now so they were not tracked so accurately but still there was intention and all known serious bugs were fixed before release was made.

Over years this policy had few changes, transforming to something like “no critical bugs in production releases” and in practice releases moved to predictive schedule rather than based on the moment when all bugs were fixed.

To tell you the truth this was inevitable – with so huge amount of users as MySQL has and growing MySQL complexity you can’t hope to have zero bugs, especially as some bugs are design bugs which require a lot of work to get fixed. But at the same time MySQL for very long time kept silence about known bugs in releases – the bugs were in bugs database of course but it is quite complex to get them out of there in systematic form.

Finally now MySQL takes next step and documents known bugs in MySQL 5.1 As you can see the list shows target fix for the bugs and targeted fix date – so you know which bugs will be fixed in 5.1 and which will have to wait for future versions.

I can only hope this is not going to be one time event and we will get maintained list of most important issues with most recent stable version which is updated as new bugs are found.

About Peter Zaitsev

Peter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.

Speak Your Mind

*