What if

For the last 2-3 years, Brian Aker and I have had many discussions about how to refactor MySQL. Brian has been the one driving these discussions by asking why some things in MySQL were done in a certain way and in a true "what if" manner asked what would happen if we would do things in another way.

Being tired of not being able to get critically needed reconstruction work done in the MySQL server, Brian started to work on Drizzle to search for answers to these questions.

So what is Drizzle?

• Drizzle is what MySQL would be with a more interactive community involvement in the design of the software itself, and had targeted website deployments.

• Drizzle is a version of MySQL that is driven by Brian and the community, attempting to solve practical problems that a large group of MySQL users are facing.
  

• Drizzle is a smaller, slimmer and (hopefully) faster version of MySQL; Features that the broad Drizzle community does not want or need are now removed or in the process of being removed (This includes stored procedures, views, triggers, grants, some non-pluggable storage engines and more).

• Drizzle is the 3rd fork of MySQL server code base, but is the one that has (for now) the most developers working on it. The two other forks are:
• ProvenScaling's fork on mirror.provenscaling.com provided by Jeremy Cole. You should read Peter Zaitsev's blog about this.

• The MySQL-5.1-maria fork, provided by the Maria team lead by me. (Brian did beat us when it comes to opening up the tree for outside development; We are still at least a month away from doing this).

• You can find out more about Drizzle at Brian's blog at http://krow.livejournal.com/.
  

Why is it that the people working on Drizzle are extremely enthusiastic about Drizzle?

This is because Drizzle solves many of the problems that MySQL's development has had for years:

• It opens up MySQL development for the community; You no longer have to wait years to get your patches and resonable extensions into the server.

• Critical bugs that have existed for years can finally get fixed as the development is no longer constrained by unrealistic release schedules that put artificial constraints on things that can be fixed.

• Drizzle will put some MySQL server differentiation on a true test; A bit like Fedora does to RedHat.

• Drizzle has created new excitement in the MySQL developer community; A lot of people seem to be very enthusiastic to work on it in a true community-oriented manner.

• Developers working on Drizzle is doing drastic refactoring of the server, something that MySQL planned to do years ago but never happened.

• Development decisions is again driven by people that are using the server daily; This will ensure that Drizzle will be faster and more stable than what can be done with current MySQL development model

• Drizzle will target the MySQL core users, the web users, whose requirements have been ignored for years while the core MySQL developers have added features that they don't need.

• In addition Drizzle will include the latest InnoDB code; You don't have to wait for MySQL 6.0 or go to the trouble of annually downloadoing and installing the InnoDB plugin from Oracle just to get access to the latest and fastest InnoDB version.

That said, Drizzle is not here to replace the normal MySQL server; Drizzle targets a limited but important market and will thus help us the enhance the MySQL based offerings. Think of Drizzle as the microkernel server around which other offerings/features can be developed.

Drizzle has no release schedule or timeline, but will follow a true open source and agile methodology of releasing early and releasing often; Brian expects that there will be a usable, reasonably stable version of drizzle within 3-4 months, but there are no promises.

Drizzle will also be of great help for the 'normal' MySQL developers; By looking at how Drizzle is solving things and by constant benchmarking against Drizzle, we will get a better insight into the weaknesses of the current codebase and have a better idea of what needs to be fixed; Friendly competition is good!

Drizzle is one of the good things that have been made possible by Sun acquiring MySQL. Brian has been working on Drizzle with the blessing and encouragement from Sun's upper management. We are finding Sun to be open and encouraging of innovation, this has been a good aspect of the acquisition.

My personal reaction to Drizzle is that I am very enthusiastic for this new kid on the MySQL block. I don't agree with everything that is done, but most things makes a lot of sense. I am looking forward to a lot of very interesting discussions about solutions in Drizzle that will help improve both MySQL versions.

A bugs life

This is a request to all MySQL users to help mysql developers, by providing information, so that we can help you, by providing a more stable MySQL server for your needs.

As you may know, MySQL 5.1 has been in state of release candidate (RC) for some time. The last RC was announced as the last RC and is supposed to be followed by a GA release. The GA release is planned to be the exact same code as the last GA, only with the label changed.

The question we, who are developing and supporting the MYSQL server have been asking ourselves is, "Are really now in shape to do a proper GA release?".

We would like you as a MySQL User to help us out with deciding this.

We don't want to repeat the mistake we did with MySQL 5.0 GA and then again with MySQL 5.1 RC, by releasing a MySQL 5.1 GA too early.

Our external criteria for General Availability (GA) or Production release can be found here.

What you may not know is that we have as part of our internal GA criteria, a requirement that we should not have any serious bugs, crashing or wrong result bugs, that affects a notable amount of users. The criteria states that it is ok to postpone fixes for bugs that have a low impact (ie affects few users).

This has the following implications:

• Bugs for which we don't have many user/customer reports for are not likely to get fixed. (In the worst case not even in 6.0 !)
• It's ok to go out with bugs in new feature in the GA as long as we don't have many users/customers that have reported problems with these features.
  

In other words, if you have an issue with a serious bug that exists in 5.1 that you *really* would like to have fixed soon now is your chance to influence our development!

Note that it's ok, and we want, you to also report bugs after we release the MySQL 5.1 as GA. The more users/customers commenting on a bug the more chance it will be fixed!

What I would like for people to do:

• Report every single bug that you encounter or know about in 5.1 into our bugs system.

• If the bug is already reported, please add a comment to the bug report that it affects you too.
• If you are a MySQL support customer, add either a note to the bug report that you are a customer and the bug affects you or send a request as a customer directly to the MySQL support personal (they are happy to take your reports!)
• If you have reported a bug a long time ago that has not been fixed and this is still important for you to get fixed, please reopen the bug/add a note in the bugs database that the bug is still relevant for you!
  

Note that you should also do this for bugs that you know of in MySQL 5.0 that are still open for MySQL 5.1 (or any bugs that are labelled to be fixed in a future release). Bugs that are in earlier version are also very likely to also be in 5.1 if the bugs database doesn't say otherwise.

Lets make the MySQL server bugs life's harder by giving us more information about which bugs are really important for us to fix. More information will help us make better decisions about how and when a bug should be fixed.