A year ago I posted a blog on The state of MySQL forks: co-operating without co-operating. (Also Giuseppe wrote about the topic at that time, and Peter Zaitsev covers it in his conference keynotes.) So I've been wondering if it would be good to write an update on the topic now, and in that case what to write.

There's now 2 weeks left of the Call for Papers for Percona Live MySQL Conference and Expo (Santa Clara, CA). This weekend I've been finalizing my abstracts for submission and I trust many of you are doing the same. (If nothing else, do it for the free entrance! Or because you're passionate about MySQL, yeah, that's what I meant...)

This is the main annual MySQL event, so I thought it is worth the bandwidth to use these two weeks for some discussion and brainstorming. We are the MySQL community, it's up to us to make this a great conference now! This year I'm on the program committee, so I'm looking forward to reviewing many, many great proposals. At the same time, I'm interested to hear what you, dear readers - and hopefully future conference visitors - are interested in seeing at the conference? I'll share my ideas here and you can share yours in the comments or if you prefer you can email me at henrik.ingo [at] avoinelama.fi.

Suomeksi: MySQL käyttäjätapaaminen Helsingissä 1. marraskuuta. Klikkaa allaolevaa linkkiä ilmoittautuaksesi, siellä saat myös lisätietoa suomeksi.

Finally it's here! So many of you have always asked about it. Markus and other Elisa guys. Osma and Ilkka at Habbo Hotel. And others... MySQL was born in Helsinki, InnoDB was born in Helsinki, a lesser known database / also MySQL engine called Solid was born in Helsinki, and 2 great replication companies, Continuent with multiple generations of clustering for MySQL, and Codership with Galera, are Helsinki companies. And amidst this embarrassment of riches, what did we not have?

A MySQL User Group.

In December I covered the topic The state of MySQL forks: co-operating without co-operating (which was also a response to Giuseppe Maxia's take on the same topic). Since half a year has now passed, I was wondering if I should follow up with an update. (Drizzle having a GA release would be the major news in such an update.)

But I see that Peter Zaitsev covered this topic in the opening keynote of their Percona Live conference. Since I agree with Peter's view on this topic, I just recommend you watch the talk on Percona.TV. He also uses the same categorizations of the forks, and includes "community patches" as its separate slide.

In March I posted a series of blog posts on my paternity leave MepSQL project, which I called MepSQL. There was still one piece created in the MepSQL buildsystem that I didn't publish or blog about. Since it is generally useful, I wanted to generalize and polish it and publish it separately. I finally had that done last week, when I also found that somebody else, namely alestic.com already published a similar solution 2 years ago. So yesterday I ported my BuildBot setup to use that system instead and am happy to publish it at the Open DB Camp 2011 in Sardinia.

Ok, so let's go back a little... What is the problem we are solving?

Let's refresh our memory with a picture (and you can also go back and read about it):

Friendly and without drama

That's a good way to summarize the MySQL conference 2011. Nobody acquired nobody. There were no volcanoes keeping men away from their wives, dads away from soon to be born babies. I had packed extra underwear just in case, but it wasn't needed.

Jonathan Levin has an excellent blog post titled How to make MySQL cool again. It is almost word for word something I've wanted to write for a long time. Now I don't need to, thanks Jonathan.

Once again Blogger failed to post my comments to his site, so I will make some comments as a new post of my own instead. Jonathan actually lists things that exist already but isn't getting used enough. My list contains also a few things that I don't know if they exist or not.

Hi Jonathan

This is just a friendly reminder that you can nominate your favorite MySQL community member, application and company for the traditional awards. The nominations must be in by the end of this week, after which the panel votes on them:

https://openlife.cc/blogs/2011/march/call-nominations-2011-oreilly-mysq…

I've seen at least a few people on IRC that were thinking of sending in nominations, now is a good time to do it!

The address is mysql.awards [at] gmail.com

This is the final part in a series of posts about the MepSQL build system known as MepSQL Bakery. MepSQL is a (yet another) fork of the MySQL database server, with the server based on the MySQLatFacebook code and the build system based on the MariaDB build system.

In this final post I wish to draw a high level picture of the complete process of building TAR, DEB and (eventually) RPM packages from the source code. There's not much more technical details to add to the previous posts, instead I'm going to make some, shall we say "archeological", observations which imho are interesting given how the build system has evolved when being passed from one project to another. Perhaps more importantly, I will also say a few words about where I think the future direction lies.

Yesterday I wrote down the approach used in the MepSQL build system to parameterize the TAR package name produced. Today I will follow up with how the same was done for building DEBs. The motivation is to create a system that can be used flexibly to create packages of any MySQL fork, with any brand name: mepsql-server-*.deb, percona-server-server-*.deb, mariadb-server-*.deb or even just mysql-server-*.deb (which I might do some day).

While yesterday's tricks with the TAR files were rather straightforward, with the process of building DEBs this turns out to be much more challenging. But not to worry, like my former collague Bernhard Ocklin used to say: This is software, anything is of course possible.