With 130 entries in the “MySQL” category and no MySQL-related subcategories, my blog had become impossible to search and navigate easily.

And thus I created a number of new categories for the MySQL entries within my blog. They’re listed in the left navigation bar, below the months, as well as below:

• MySQL Server, MySQL Cluster, Falcon
• Connectors: PHP, Ruby on Rails
• Tools: GUI, MySQL Workbench, MySQL Proxy
• Events: MySQL Users Conferences
• Licensing: GPL
• Architecture of Participation, Summer of Code, Virtual company
• Other: Release Policy, Documentation, Use cases

I hope this will make my blog more (re)usable.

(The picture is from this summer, when navigating the way up the Großvenediger, a 3662 m high mountain in the Hohe Tauern region of Austria.)

Stefan Hinz, MySQL’s Docs Team Lead, just showed me the new restructured documentation overview page http://dev.mysql.com/doc/. The intention of the restructuring is to make it easier for you to find the information you need.

We’ve amended the MySQL Reference Manual section with a subsection labeled “Excerpts from the Reference Manual“, examples of which are a standalone Connectors book (covering all MySQL connectors and APIs) and guides for each individual MySQL Connector.

The key new document there is the “MySQL Server Version Reference” that should make life easier for everyone who needs cross-version information. It’s available for download but you can also browse it online at http://dev.mysql.com/doc/mysqld-version-reference/en/.

Here’s an overview of the MySQL Server Version Reference document:

1. The mysqld Options/Variables Reference contains all MySQL server options and variables for all MySQL versions. You can easily find out whether or not a particular option is available in a specific MySQL version, when it was introduced or deprecated, and more. For variables, that chapter gives a quick overview of core properties, such as if it’s a status or a server system variable, if I can be changed dynamically, or if the scope is global or local.
2. The Reserved Words list contains all words reserved in a particular MySQL (major) version, with annotations about minor versions. The list is created by running a script against all MySQL versions starting from 4.1.0. (Yes, our Docs Team has installed all MySQL versions on their documentation machine!)
3. The Functions and Operators chapter shows which MySQL functions are available in which version, and when they were introduced or deprecated.
4. The Build (configure) Options chapter should be useful for anyone building MySQL from source.
5. Eventually, the Key changes in MySQL releases chapter lists security fixes and incompatible changes for the GA versions of MySQL 4.1 and 5.0 and for the beta and RC versions of MySQL 5.1.

The Server Version Reference is not a static document but is being recreated on a regular basis.

Kudos go to Martin C. Brown who created all this. We hope it will make your work with MySQL more productive and enjoyable!

References:

• Improved MySQL Documentation overview page http://dev.mysql.com/doc/
• New MySQL Server Version Reference document: http://dev.mysql.com/doc/mysqld-version-reference/en/

First of all: Thank you for your positive feedback on the MySQL 5.1 Errata Sheet!

While I never doubted that publishing the 5.1 Errata Sheet was the right thing to do, I had expected a more mixed feedback. It turned out the feedback was very grateful. So thank you for your encouragement

• Kevin Burton for commenting in Jay’s blog
  

  “This was a big win guys. Good work.We were going to deploy 5.1.x in out or production slave configurations just to test the reliability but this give us a lot more confidence in this release.”

• Baron Schwartz for commenting in my blog
  

  “Kaj, this is VERY helpful. I just discovered the character set issue with mysqldump myself last week.This is a big step forward in quality, from the user’s point of view. Now it’s much easier to see the state of things.”

• Peter Zaitsev for explaining some background in the blog entry “Making bugs public - good job MySQL”

The Errata Sheet had somewhat of a difficult birth process, as our pompously titled “Release Philosophy” page optimistically refers to the ideal situation of “no known critical bugs”. If we follow that policy, there is no need for an errata sheet, is there? The Errata Sheet should by definition be empty.

But it isn’t.

And it wouldn’t have been, for the last four years, had we just had sufficient awareness of critical bugs, and a policy of publishing them.

The only logical conclusion from our Reality Check was that wishful thinking must stop, and we need to do the right thing under the circumstances: Get the best possible quality releases out with the given resources, and set the expectations of our customers and users according to what we can and will deliver.

And hence we appointed a cross-team working group, the “Release Criteria Committee“, which is defining both external and internal processes and policies when it comes to

• releasing new releases in general
• moving from one maturity stage to another
• dealing with bugs of all kinds
• aligning MySQL release policy documentation with reality

So let’s first look at the circumstances:

• Resources are finite: There is only so much time in a day, and there are only so many developers around to fix bugs.
• Timely releases have value to our users: Earlier access to bug fixes. Earlier access to new features. Earlier testing of both, i.e. faster convergence. Reduced guesswork about when the next release will be.
• Zero critical bugs is impossible: Sure, zero bugs is desirable. And at times, we internally glorify MySQL’s past, with “production level alpha releases”. Those were the days, but those days also had less complex and less interwoven features, and fewer developers to manage.

As such, it is MySQL’s responsibility to create a release policy that is aligned with the needs of the customers and the user base. This will involve a number of difficult judgement calls. However, we do think that we’ve got a lot to learn from our customers and users, when it comes to defining the best possible release criteria. So I am inviting your input.

To structure your thinking and the work, let me briefly explain some basics:

1. We have four maturity levels: Alpha, Beta, RC and GA.
1a. Alpha is for testing and development only. Features are added, and
syntax may change. (*)
1b. Beta means feature-freeze. We fix bugs. (*)
1c. RC or Release Candidate needs solid criteria. RC has some industry definitions, and is the final stage prior to GA.
1d. GA or General Availability means the version is for production use. The name GA is somewhat silly for Open Source products, as even alpha releases are available for the general public.
(*) These are my own simplifications, and our work group may refine them.

2. Bugs are described by their Severity, Defect Classification, Impact, Risk To Fix, and Effort. They may have even more dimensions.
2a. Severity describes the damage from the original user (bug reporter) point of view. The most severe bugs are about crashes, security problems and corruption, without any known workaround. The least severe refer to unpleasant but documented behaviour, i.e. feature requests. From the severity of the individual original reporter, we derive the Defect Classification, which attempts at being a neutral classification across our user base.
2b. Impact refers to how many users may be affected. They range from
the entire user base, all the way to corner cases that affect only users of a particular feature on one platform.
2c. Risk To Fix and Effort refer to the difficulty of fixing the bug. A bug fix may destabilise the code (i.e. introduce more problems than it fixes), requiring postponing the fix to a later version. And the time for fixing the bug may vary (influencing the complexity of reviews).

Some of my personal thinking on the release policy is as follows:

(i) Maturity changes need quality criteria.

• Progressing from Alpha to Beta is not useful if most testers find the same elementary critical bugs; basic usability should exist
• Progressing from Beta to RC needs for the impact of critical bugs to be very low
• Progressing from RC to GA needs the impact of critical bugs to be even lower
• Hence, I advocate quality based (not time based) release criteria for maturity changes

(ii) New releases within the same maturity level need different quality criteria (from above).

• Regression bugs must be avoided (what worked in release n must still work in release n+1) (**)
• Beyond that, we mainly need for the quality of release n+1 to be higher than that of release n. In practice, if you look at today’s (10 Nov 2007) version of the Errata Sheet, you will see a lot of bugs annotated with “Already fixed in 5.1.23″, while others have “Target fix: 5.1.23″. “Let’s not wait until we can cure all illnesses, before handing out the medicine we already have!” is my logic.
• Hence, I advocate mostly time based (seldom quality based) release criteria for new releases within the same maturity level
• (**) By “regression bugs” I mean unintentionally changed behaviour, i.e. pure bugs. There may be situations where behaviour has to be consciously changed to enable the fixing of a bug.

(iii) Simplicity rules.

• The definitions of the dimensions that describe bugs must be as simple as possible.
• The rules triggering maturity changes must be as simple as possible.
• It should be easy at any point in time for us to evaluate whether we should change a maturity level (as opposed to being a negotiation between self-proclaimed advocates of quality and timeliness, respectively)

(iv) Timeliness has a value, and RC criteria may differ from GA criteria.

• Some claim that by definition, an RC must fulfill all GA criteria except the exposure to wide user base testing
• Others (like me) think that it’s in the best interest of the user base to converge to a GA quicker, through marginally relaxed RC criteria, whereby we can fix the remaining less-critical bugs in parallel with the RC getting exposed to massive parallel testing by the user base

When we (the members of our Release Criteria Committee) think we’re done, we’ll upgrade our Release Policy (and, while we’re at it, no longer pompously describe it as a Philosophy). We’re working at a fairly hectic pace, and expect to be done within weeks rather than months.

In the meantime, your input is welcome!

As indicated last week, we have decided to start producing a condensed report of outstanding issues in our current development release, MySQL 5.1.

This list is now available as part of our reference manual at dev.mysql.com/doc/refman/5.1/en/open-bugs.html.

The list is updated daily based on the then-current status in our bug database.

The purpose of the list is to make it possible for our users to more easily make an informed judgement about whether our development release is ready for them to test and use. While the corresponding bugs have already been openly and publicly available for searching in our bug database, I hope this list is easier to navigate, as it is compiled into one web page that is sorted into categories such as

• C API
• Client
• Connector/J
• Server: Backup
• Server: Charsets
• Server: Cluster
• Server: Events
• Server: I_S (Information Schema)
• Server: InnoDB
• Server: Partition
• Server: RBR (Row-based replication)
• Server: Replication

Hence, if you’re into using Row-based replication, read through the corresponding section. Our goal is to make it easy for you to know whether any of the outstanding bugs are relevant for you.

The list also contains target fix releases (with 5.1.23 currently being the next one), and links directly into the bugs system for detailed inspection of the bug description.