Today I'm coming out of the closet. Since I'm a professional database expert I try to be like the mainstream and use the commercial MySQL forks (including MySQL itself). But I think those close to me have already known for some time that I like community based open source projects. I cannot deny it any longer, so let me just say it: I'm a Drizzle contributor and I'm very much engaged!
I've been eyeing the Drizzle project since it started in 2008. Already then there were dozens of MySQL hackers for which this project was a refuge they instantly flocked to. Finally a real open source project based on MySQL code that they could contribute to, and they did. It was like a breath of fresh air in a culture that previously had only accepted one kind of relationships: that between an employer and an employee. Drizzle was more liberal. It accepted also forms of engagement already common in most other open source projects that are based on relationships between 2 or more consenting contributors.
But in 2008 I wasn't yet ready to engage with Drizzle. Like I said, I worked in a role where I would go to database users and help them use MySQL in demanding production settings. So as much as I admired Drizzle already back then, I needed something that could give me good releases, and support me when needed.
In my previous post I explained why I believe the production of RPM and DEB packages should be more integrated with the rest of your development process. Now it's time to look into how you can put the RPM build scripts inside your main source code repository, and in particular how I did that to produce RPM packages for Drizzle.
Last weekend I released rpm files for the latest Drizzle Fremont beta (announcement). As part of that work I've also integrated the spec file and other files used by the rpmbuild into the main Drizzle bzr repository (but not yet merged into trunk). In this post I want to explain why I think this is a good thing, and in a follow up post I'll go into what I needed to do to make it work.
(And speaking of stuff you can download, phpMyAdmin 3.5.0-alpha1 now supports Drizzle!)
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):
With this release I also announced my intent to hand over the module to a new maintainer. Since I'm now increasingly active with affairs in the MySQL community, both hacking as well as other community tasks, it is prudent to not let old projects dangle without attention but to formally hand them over to fresh minds.
As some Facebook friends already guessed from my status updates this week, my 9 month paternity leave is now over and I've survived my first week back in work life, waking up at seven in the morning! This is just a personal-life blog post to let everyone know what I'm up to, (For those asking: Ebba is doing fine, she recently started to stand up and even takes steps if I hold her hands.)
During the past months I had many interesting conversations and ideas of what to do next, but in the end Nokia was the company standing out with a very interesting offer. So as of last Tuesday I work at Nokia as Senior Performance Architect in the Mobile Solutions division, better known as the Nokia Ovi web services.
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:
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.