Kevin Burton, CTO of TailRank.com, approached me a few weeks ago about the possiblility of having a MySQL hackfest in a style similar to Barcamp's grassroots flavour. Kevin and I talked yesterday to hammer out a few first logistical questions, and have made a few preliminary decisions.

The dates we have picked for the MySQL camp will be November 10th through 12th (Friday through Sunday). We picked these dates partly because a number of key MySQL figures, including Monty and David, will be in the valley for a board meeting that week. I believe it is important to have at least a few MySQL developers who know the MySQL server code inside and out to be present at the camp to ease the (substantial) learning curve when investigating the server internals. Hopefully, Brian and a few other developers …

So, things are progressing at a fairly decent clip towards getting the groundwork for a MySQL build farm going. The Forge wiki Build Farm Initiative has been updated with various ideas (thanks, Ronald!) so please go vote for features you want to see in the farm, and let us know your ideas for the system. Also, I have started a new wiki page called Build Farm Inventory, which is simply a springboard page to get an inventory of hardware that community members are willing to enlist in the farm. I've started things off by adding one of my own boxes. If you're interested in participating in the endeavour, please feel free to add your own boxen to the list.

Secondly, I've been going through the documentation that Kristian Nielsen provided me about the internal pushbuild software …

In addition to our main MySQL Users Conference that took place in April, there will also be two small MySQL Conferences in Europe later this year. There will be presentations about our products and roadmaps as well as sessions about best practices and first-hand customer experiences. You will also get a chance to meet and talk with many MySQLers and share your thoughts and experiences. The conferences will take place in London, UK (Tuesday, October 17th) and in Munich, Germany (Thursday, October 19th). The conference program looks very interesting and there is an early bird discount, if you register before August 31st. So don't hesitate to register soon!

A couple of people have written in reporting innotop crashes. Unfortunately I don't have access to enough variations of operating systems and MySQL versions to test everything myself, but if you're able to help by sending me a bug report when innotop crashes, I'm willing to work on fixing it! I hope soon I'll have a much larger test suite, and am grateful for your help with that. This article explains what information I need to reproduce and debug crashes.

I've made several improvements to the innotop InnoDB and MySQL monitor, and it's ready to get from the download link on the original article.

A couple of people have written in reporting innotop crashes. Unfortunately I don’t have access to enough variations of operating systems and MySQL versions to test everything myself, but if you’re able to help by sending me a bug report when innotop crashes, I’m willing to work on fixing it! I hope soon I’ll have a much larger test suite, and am grateful for your help with that. This article explains what information I need to reproduce and debug crashes.

ruby has two modules for connecting to mysql. one is called mysql/ruby and is built in top of the standard libmysqlclient c library. the other is called ruby/mysql and is pure ruby. the problem with the latter is that it is a from-scratch implementation of the mysql network protocol, and the authentication handshake changed in mysql 4.1.

but here is a patch to add support for new-style mysql authentication to ruby/mysql. it should also deal with the other protocol changes that came along at the same time. it doesn?t do anything to expose server-side prepared statements.

it is only lightly tested. in particular, i haven?t tried to connect to a pre-4.1 version of the server. it should still work, …

I ran into a problem. I converted my latin1 table into utf8 with utf8_unicode_ci collation as described in my previous post. The table in question has a UNIQUE index on the utf8_unicode_ci collation column. When reimporting the data I get a duplicate entry on accent e with e itself. Why?

e == utf8 0x65
accented e == UTF-8 0xC3 0xA9, U+00E9

but the rules defined
http://www.unicode.org/reports/tr10/

say to ignore accents for unicode collations. To get around this I know to define my tables as

utf8 with collation of utf8_bin


This bug at mysql.com Here was the indicator that accent e is not the problem.

Stephen O'Grady apparently spent last week at the wrong conference. He came away from OSCON wondering if open source companies can ever reach the $1 billion mark in sales. He writes:

As stated at OSCON, I believe both that open source has reached and in fact passed the tipping point and is here to stay, and that it has a bright future. At this point, however, I do not expect any of the major pure open source firms to challenge the billion dollar threshold any time soon. The numbers - those that are available, at least - simply don't support such a conclusion. But neither do I consider that a metric for success.What's interesting to me is that the very same numbers - at least, I assume we have access to the same data - tell me a very different story. Red Hat will hit the $1B mark in 3-5 years, and will likely do so without seriously tapping into …

Just as a reminder that the MySQL meetup will be happening next Monday at the Elysian.

Directions to the Elysian can be found at:
http://www.elysianbrewing.com/Elysian.html

Our normal range of topics will be covered... aka we talk about MySQL for about half the evening, and then we spend the rest of the evening geeking about other Lamp projects and who has tricked out their MythTV in the last month :)

I'll do a wrap up of what I saw at OSCON last week.