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!)

Hi again

It's time to announce the next Helsinki MySQL User Group which is on February 8 at 18:00. Venue is Solinor's meeting and sauna facilities in North Haaga: http://www.meetup.com/The-Helsinki-MySQL-User-Group/events/42163422/

By popular request, Monty will be sharing news about MariaDB, after which there is the usual food, beverages, sauna and socializing.

The organizers would really appreciate it if you could RSVP at the meetup request above. Last time the place was already packed and now with this kind of superstar speaker the hosts want to make sure they book an appropriate room and enough food. (Seems there's already 20+ going!)

See you there!

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@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):