Thursday, 18 January 2007

MySQL continues providing Windows binaries for free

Contrary to some reports in the community, MySQL will continue providing binaries both for Windows and other operating systems. All our download pages, including those for MySQL 5.0, have binaries today, and will continue to have them.

The source-only releases we introduced with 5.0.33 (and will continue to provide in the future)are just in addition to the binary-and-source releases. The current latest binary-and-source MySQL Community Server release is 5.0.27, and I expect MySQL 5.0.35 Community Server to be released as binary-and-source within a month, both for Windows and our other platforms. This is as we always planned it, and tried to communicate it. I am sorry our communication has not been clear enough.

Wednesday, 10 January 2007

MySQL 5.0.33 Community Server released

MySQL Community Server 5.0.33 has now been released. It is a pure bugfix release, delivered in a source-only form as a tarball for Unix and for Windows (we provide separate sources for these, as the build procedure differs) on dev.mysql.com/downloads/mysql/5.0.html#Source.

The release contains all bug fixes applied to MySQL Server 5.0 since the last Community release 5.0.27 in October 2006. The jump in numbers from .27 to .33 is to make it clear that .33 is up-to-date to the level of MySQL Enterprise Server 5.0.32, released about two weeks ago. We reserve the even version numbers for MySQL Enterprise, while odd version numbers indicate a Community Server Release. Both use the same "5.0" version part, as they share the same code base.

We are in the process of applying several patches provided by Community members, currently in our Contributions Pipeline. I expect several of these enhancements to be merged soon enough for the next MySQL Community Server to be released in February as 5.0.35. On the contrary, they will not appear in MySQL Enterprise Server 5.0.

The release notes for MySQL 5.0 have been split into separate sections of the MySQL 5.0 reference manual. This means that the documentation of the bug fixes of MySQL Enterprise Server 5.0.28, 5.0.30 and 5.0.32 have been copied into the release notes for MySQL Community Server 5.0.33.

The purpose of this MySQL Community Server release is twofold:

a) to deliver recent, fresh bug fixes to the MySQL community
b) to establish and test the practice of source tarball releases

As such, the bug fixes have been available in source form both as part of the BitKeeper source repository on mysql.bkbits.net and as MySQL Enterprise Server source releases on our ftp site ftp.mysql.com. However, we believe Linux distributions and Open Source fluent community users of MySQL are better served by a tagged MySQL Community Server release, which is available on our download server and has one single set of release notes.

Through establishing source tarball releases, we follow the tradition of many other FOSS projects. This provides more possibilities for Community Contributions in the means of binary builds.

We refer to our reference manual, especially the chapter 2.4.14. MySQL Installation Using a Source Distribution when it comes to building MySQL Community Server. At the same time, I want to point out that the service of providing MySQL Enterprise Server binaries is something we do for our paying customers, in the form of the MySQL Enterprise Server subscription, starting at 595 dollars a year.

We strive to release MySQL Enterprise Server on a monthly basis. While we don't have a specific schedule or policy for when MySQL Community Server is released in binary form, I expect the next Community release, 5.0.35, to be available as source and binaries for the same platforms as MySQL Enterprise Server and as the previous MySQL Community Server binary release 5.0.27. Until that point in time, the 5.0.27 binaries will be the ones listed on the normal MySQL 5.0 download pages at dev.mysql.com/downloads/mysql/5.0.html.

Distributors of MySQL Community Server are welcome to contact Colin Charles and Lenz Grimmer, with proposals for process improvements (at firstname@mysql.com. Better still, subscribe to the packagers@lists.mysql.com archived and public mailing list at lists.mysql.com/packagers, which Colin and Lenz are monitoring. That list as our discussion forum for builders of MySQL releases, both already existing ones like the various distributors, and for new community contributors that want to step up and provide binaries, including Windows.

Please note that while the release has undergone testing, 5.0.33 is our first source only MySQL Community Server release, so I expect there to be some room for process improvement on our side.

Amongst the bug fixes, there is one that I want to highlight. It is listed as the innocent-looking bullet "InnoDB showed substandard performance with multiple queries running concurrently. (Bug#15815)". This is a fix to an issue especially surfacing on multiple-core processors. You testing in such environments is much appreciated. As a reference, you may want to read the Bugs database entry bugs.mysql.com/15815 as well as two articles from Peter Zaitsev -- one from a week ago, another from last September.

Friday, 5 January 2007

How to arrange a physical meeting in a virtual organisation

A few weeks ago, nineteen MySQLers had a successful meeting in Berlin. The QA and Build teams invited some guests from other Engineering teams and from Support, and we experimented with a couple of new meeting practices. We're not yet at Meeting Nirvana, but we felt that we had taken great strides compared to several earlier MySQL Dev Mtgs.

Plenty of literature and blogs exist on arranging good meetings. The scope of this blog article is limited to physical meetings in virtual organisations, i.e. collecting a group of people who work together every day but see each other once or at most twice a year. That special context puts the emphasis on certain decisions and practices, which I attempt at highlighting below.

The twelve items come in a chronological order.

Before, during and after the meeting



1. Set the right meeting goals.



  1. Try to solve fewer problems than you would like to at first sight, but solve them properly. Nobody benefits from reheating old ideas over and over. Everyone benefits from getting rid of issues permanently.



2. Use Wiki from preparations to storing persistent notes.




  1. Have one persistent, easy to access, easy to maintain storage for all meeting related information, from womb to tomb: The company-internal Wiki. This saves on redundancy: no copying between formats, no updating from here to there and back, no email attachments, no confusing old copies lying around.

  2. Use Wiki to prepare and plan sessions virtually before the meeting. Cut down on email.

  3. Encourage the use of Wiki even for presenting information on screen during the meeting. Allow Keynote, PowerPoint or Open Office Impress, but don't specifically encourage it, and by no means require it. True, "slide borders" don't exist in Wiki and a classic presentation focuses the attention on what the presenter displays at the moment. But the savings on redundancy related costs are huge, if you skip slides.

  4. Share notes right after the session. Mandate the scribe to clean up the notes and notify relevant people over email within 2-3 hours after the session ended. In the email, include the URL for the Wiki page, but paste the contents in acceptable format, so attendees who wish to do so can read the notes when flying home without Internet access.
  5. Store notes persistently in Wiki. This is useful when the action items are being worked on, put into Worklog (task management system), and reviewed at follow-up meetings. Use the store as an archive, a reference, a role model e.g. when related sessions are planned at future meetings.



3. Concentrate on Action Items and Policy Changes.




  1. Consider the prime success measure of the meeting to be the quantity and quality of Action Items and Policy Changes that are clearly documented as a result of the meeting. True, meetings should also set common goals, instil a fighting spirit, share information, boost morale, and be fun. But the considerable cost of flying people to one location can only be justified by getting more work done when together, rather than dispersed. And few things boost morale, instil a fighting spirit and are fun, as much as the feeling of accomplishing relevant work together.

  2. The moderator shall, by directing the discussions, focus on moving forward ideas over well-formed thoughts and proposals to actual action items and policy changes. And so shall the scribe, by phrasing and pointing to incompletenesses. And so shall the participants, by supporting the goal of the topic at hand and by avoiding distractions.



Before the meeting


4. Pick the right location to minimise travel cost.




  1. Use the cost per participant meeting day as the key performance indicator of the financial success of the meeting. Count in flights, trains, accommodation, meeting rooms, internet, dinners, entertainment, everything related to the meeting, and divide it by the number of participant meeting days. If twenty people meet for two days, and then just ten continue for another three days, we have seventy participant meeting days.

  2. Set the meeting date early, several months in advance. This enables cheaper flight tickets, and less hassle for attendees from Russia, the Ukraine and other countries requiring visas.

  3. Pick a place with some local attendees.This not only saves on travel cost, but simplifies the choice and booking of hotels and restaurants. For MySQL Dev Mtgs, good places are at least Moscow, St. Petersburg, Kiev, Helsinki, Sofia, Berlin, Vienna, Uppsala/Stockholm, Heidelberg, Munich, Paris, Dublin, Austin, Cupertino, and Seattle, in rough order from east to west.




5. Invite the right participants (only).




  1. Require every participant to contribute before, during and after the meeting. If they don't contribute, why go through the trouble and cost of travel?

  2. Don't let distance pose an artificial barrier for invitations. Although trans-atlantic flights are more expensive than flights within Europe or within the US, with early enough planning, the difference can end up being relatively small. In Berlin, we made at least one mistake on the side of being too restrictive.

  3. Be sure to invite guests from cooperating departments. Having invitees from stakeholder departments is both productive, revealing, and fun. In Berlin, we had three Support engineers (superb!), a Community guy (in addition to myself), and a number of Developers, in addition to the core group of QA and Build engineers. We could have done with a few more guests, such as someone from Marketing.



6. Issue a formal Call for papers to identify session proposals.



  1. Don't believe that you know all relevant topics yourself. The collective body of intended participants sits in with a lot of good judgement, on what you need to focus on in order to achieve the overall meeting goals.

  2. Require people to go through the trouble of identifying individual sessions. What topic? What should the session goal be? Who can moderate? Who should attend?

  3. Require the proposal to be delivered over Wiki in a predefined format. Use that Wiki page for keeping track of the session before, during and after the meeting.

  4. Be firm on the deadline you set for the CfP. Time before the meeting is in shorter supply than you believe.

  5. Iterate to improve the quality of the session proposal. Involve others, once the proposal has first been written.


7. Prepare the sessions: Require proposals for process changes, action items.



  1. When selecting sessions, be heavy on those involving decisions, process changes, and action items. Be light on information spreading.

  2. For each session, ensure that there is at least one actual proposal, if not several, prior to the meeting. Valuable face-to-face time shouldn't be wasted on stuff that could have been done in solitude prior to the meeting.

  3. Require people to read the proposals prior to the meeting. Again, reading is a waste of face-to-face time.



During the meeting



8. Identify moderators and scribes, support them, expect them to excel.




  1. As moderators, pick those who have leadership skills to keep the sessions on track. They must be able to realign the attention with the goal of the session, and know the technical topic and participants well enough in order to know when to intervene. The moderator does not have to be the best technical expert on the subject.

  2. As scribes, pick those who can express themselves precisely and simply in writing. They must be able to support the moderator in getting well-formed Action Items. Their subject matter knowledge can safely be on the lighter side. And if possible, they should be fast typists.

  3. Take even more care in picking the scribes than the moderators. People who can capture process changes, action items, and rationale in a compact, easy to understand form are in short supply.

  4. Reward good scribes during the meeting, by highlighting the best meeting notes. Motivate scribes (jokingly) by pointing to their power: It's their version of what was decided that is preserved for posterity, and used after the meeting.

  5. Educate scribes: Have a training session for scribes at the beginning of the meeting. Ask those who have already worked as scribes (in previous meetings) to share their experiences in those training sessions.



9. Use IRC for moderators, scribes and participants, throughout the meeting.




  1. Use IRC as an instant-messaging whiteboard. IRC should be constantly running on every participant's laptop during sessions, including the moderator and the scribe.

  2. Don't interrupt the moderator (or the person who is just now speaking) over IRC. It's hard to moderate, talk and keep your eyes on IRC at the same second. The moderator can read up on IRC notes, when others are speaking.

  3. If valuable content is being spewed out on the fly by technical experts, have the fast-typist scribe type down all of it on IRC. Don't poke fun of tyipng errrors. Encourage the technical expert to verify the notes frequently. Encourage participants to interrupt softly if wrong notes are being taken (such as by suggesting the right notes over IRC). If the technical expert is too dense and too quick, tell him to slow down. Be light on the criticism of the fast-typist scribe -- it's a stressful task.

  4. In normal meeting mode, require the scribe to type down much less: Suggested decisions, action items and important rationale (both pro and con). Encourage participants to help out by phrasing their suggestions directly on IRC, so not all of the burden is on the scribe.

  5. Have the scribe edit IRC scribblings into more final notes, when idle. And when the meeting ends officially, make it clear that the scribe is not expected to take any further notes, but should be allowed to concentrate on cleaning up the notes.



10. Spend time working together during the conference.



  1. Have topics prepared before the meeting, but not over-prepared. The suggested decisions should still be in a phase where the physical meeting can influence direction. A physical meeting is much too valuable to be degraded into a mere broadcasting forum, one person preaching, others politely listening.

  2. Set aside time for ordinary, mundane work. Not for expense reports, perhaps, but for critical solitary work where some input would be beneficial and where interruptions are OK. Short clarifications increase efficiency and boost morale in an organisation starved for face-to-face contact. "Hey, now that you sit here, can I ask you <x>?" But be sure the light interruptive questions are light, and not worth sessions in themselves.

  3. Require each participant to pre-plan one-on-one meetings and email their meeting counterparts about the meeting need, prior to the physical meeting. If not, you will find a lot of cursing about "Why didn't I talk to NN about <x>?" when the first participants drop off. "It would have been so easy to resolve a couple of items, had I only thought of it in advance." If you're in charge, encourage people to think in advance.



11. Set aside enough time between sessions to get the work done.




  1. Don't believe the session is over just because the moderator closes it. Notes have to be cleaned up, they have to be published, and they have to be reviewed. All of that takes time.

  2. Set aside time for scribes to properly clean up the notes, publish them on Wiki and send them out over email. The email should not be a mere notification with the Wiki URL but also contain the Wiki text, so that it can be commented upon in an email in parallel, or by people who are already in-flight without Internet access.

  3. Require notes to be published within 2-3 hours of the end of a session. Why? Memories have a short half-life. And that goes for the memory of the scribe, the moderator, and the participants alike.

  4. Set aside time for moderators and participants to comment upon meeting notes during several time slots each day. Memories have a half-life, remember.

  5. Be ample on the review time. Moderators and scribes are scarce resources, and they also need to sleep, eat and join at least some of the evening programme. In the meantime, less scarce resources can do one-on-one mtgs.

  6. Include short note review sessions. Here, mistakes can be corrected, and half-complete Action Items can be completed. For topics of particular importance, set aside time for longer follow-up sessions. Call them multiple-session topics, if you will.

  7. Take care, as moderator and as scribe, to involve those not present at the session. Highly relevant people, required for decisions or process changes, might have been in other parallel sessions at the moment. Or they might not even be at the meeting, perhaps staying at home in order to save the company some cost. Nonetheless, they should get the time to give their input before the next meeting day. And, if they're on another continent, they may well have prime working time at their disposal for commenting.



After the meeting



12. Follow up on action items, process changes, costs, experiences.




  1. Follow up that Action Items are properly entered into task management and project management systems. Ensure they are in Worklog (in MySQL's case), with proper references to the Wiki pages from the meeting.

  2. Follow up that process changes take effect in the corresponding process documents on Wiki, in the manual or wherever they belong.

  3. Follow up on decisions and action items in regular management meetings. Make sure the entire physical meeting wasn't held in vain, and initiatives keep on track!



Early in May 2007, MySQL AB will arrange its next Developer Meeting. We are still choosing between Sofia, Heidelberg, Munich and Vienna. We expect to considerably raise the ambition level from earlier meetings on Malta, in Prague and in Sorrento. In particular, we also expect to open up attendance for some external community members. If interested, please email both Lenz Grimmer (Community Relations Mgr, Europe) and myself at firstname@mysql.com.

Wednesday, 3 January 2007

MySQL Community Server recap

As I have seen some concerns about the release schedule of MySQL Community Server and the availability of MySQL Enterprise Server sources, let me recap and detail some of the plans, which haven't changed since the introduction of MySQL Enterprise Server in October:


  1. MySQL 5.0 Community Server sources and binaries are available from our download pages. The latest version is 5.0.27, released in October.

  2. MySQL Enterprise Server is released more frequently than MySQL Community Server. This means that we've seen also 5.0.28, 5.0.30 and 5.0.32 being released for MySQL Enterprise Server. Even numbers are for Enterprise, odd numbers for Community.

  3. MySQL Community Server gets all bug fixes from MySQL Enterprise Server. This means that the next MySQL Community Server will contain all bug fixes from the most recent MySQL Enterprise Server published at that point. If we're releasing a MySQL Community Server right after MySQL Enterprise Server 5.0.34, it will be labeled 5.0.35 and contain all 5.0.34 fixes plus any community patches applied at that point in time.

  4. The higher release frequency of MySQL Enterprise Server provides added value for our commercial customers. We intend to deliver predictable monthly Enterprise releases. Providing and verifying frequent binaries is a paid-for service for those who want to spent money to save time. That said, MySQL continues to provide new community binaries from time to time, as said in item 1 above.

  5. MySQL Community Server additionally includes what we call Community Enhancements on top of MySQL Enterprise Server. However, we've been slow at applying these enhancements. Jeremy Cole and others have been contributing patches, and we are looking at getting several of his enhancements and those of others into the tree ASAP. We are also looking at improving our processes so that contributors won't have to wait as long in the future.

  6. MySQL Enterprise Server is available in source form for download from our ftp server at ftp.mysql.com. We don't highlight this much, as we would like to encourage our community users -- including Linux distributions -- to use our community server.

  7. The MySQL Community Server tree is updated frequently with the bug fixes from the Enterprise tree. Our users can access both Community and Enterprise server from BitKeeper. However, we expect most users to want to work from tagged, numbered releases, no matter whether they use Community or Enterprise server.


One area where we feel the need to improve is the release frequency of source tarballs from the Community Tree. This will alleviate some of the burden put on a couple of Community users. Our current plan is to have the next MySQL Community Server source tarball release happen late January or early February.