Tag Archives: release

New libeatmydata release: 105

Posted on by
Reply

Over on the project page and on launchpad you can now download libeatmydata 105.

This release fixes a couple of bugs that came in via the Debian project, including a rather interesting one about some binaries not running .so ctors to properly init libeatmydata and the code path in the libeatmydata open() not really dealing with being called first in this situation.

Enjoy!

New Jenkins Bazaar plugin release! 1.18

Posted on by
Reply

From the desk of your new Bazaar plugin for Jenkins maintainer, I give you Version 1.18.

This release has two good bug fixes:

  • UI fix for checkout option (JENKINS-12261)
  • Auto-recover from corrupt BZR branches (e.g. bzr branch/checkout killed at inopportune moment) by cleaning the workspace and trying again (this is now default behaviour, best used with the Jenkins SCM retry count feature being > 1)

We’ve been running the same code as this release at Percona for about 2 months now (the second bugfix was one I wanted to test first before submitting upstream). This is the big fix that fixed all our problems with using bazaar with Jenkins in a large deployment.

The other news? I’m now maintainer, and this is my first release.

The page on the Jenkins wiki is here:

and updates should come through the standard Jenkins channels as all the auto-foo happens.

Drizzle7

Posted on by
7

We’ve released Drizzle7! Not only that, we’re now calling it Generally Available – a GA release.

What does this mean? What does this GA label mean?

You could view as a GA label being “we’re pretty confident people aren’t going to on mass ask for our heads when they start using it”… which isn’t a too bad description. We also plan to maintain it, there could be future releases in this series that just include bug fixes – we won’t just immediately tell you to go and use the latest tarball or bzr tree. This release series is a good one to use.

Drizzle7 is something that can be packaged in Linux distros. It’s no longer something where the best bet is to add the PPA and upgrade every two weeks or build from source yourself. If you’re looking to deploy Drizzle (or develop against it) – you can rely on this release.

I’ll never use the words “production ready” to describe a release – it’s never up to me. It’s up to each person or organisation looking to deploy a piece of software to decide if that bit of software is production ready for them.

Personally, I’m looking forward to see how people can break it. While Drizzle is the best tested FOSS SQL RDBMS server, I’m sure there’s new an interesting ways it can be broken by saying we’re ready for a much larger crowd to hammer on it.

Overall, I think we’ve managed to take the now defunct MySQL 6.0 tree (way back in 2008) and release something that can truly live up to the line “database for cloud”. Drizzle is modern, modular, rather solid and understandable. The future is bright, there is so much more to do to make the ultimate database for cloud. Drizzle7 is a great platform to build on – both for us (developers) and us (people who use relational databases).

thoughts on MySQL release cycle

Posted on by
1

Thoughts on latest changes:

  • don’t think there’s really much to it.
  • I rather disagree with this slashdot headline (MySQL Closing Off Its Source) as I just don’t think it’s true.

However, I have other thoughts (that are a lot more interesting to discuss):

We should:

  • Release major version every 6 months. e.g. N.0, N.2, N.
  • Odd numbers are used during the 6months of development, with very frequent releases. In fact, with a strict policy of keeping pushbuild green, you could automate this. Yes, some of these releases would be utter shit due to whatever problem seeped in. Get over it – it’s called a development release.
    • No new features merged for last 3 months of cycle for release.
    • source only releases… if you can’t build from source then you’re too stupid to run this. (or, diplomatically “you shouldn’t run this”)
    • For features that take longer than 3 months, we can have a “-proposed” patch set. i.e. a staging area for new things before they go in.
  • Minor versions to latest N.x when needed (N.x.z)
    • Until the next N.x version, where N.x-1 is forgotten. I mean forgotten as in no patches at all… others can if they care.
  • Pick a N.x and support it for Y years (a good N.x that is)
    • i.e. provide N.x.z
    • this can be our “RHEL” so to speak.
    • fixes go here.
    • call it ‘enterprise’ or whatever.

Past problems:

  • 5.0 took too long to get to a real GA status
    • A bunch of things were broken in that release cycle… Although I joined it relatively late.
    • It’s been a decent release for a good while now, so that’s a good thing.
  • 5.1 has taken too long to get to GA
    • good news is that 5.1 at GA should be a lot better than 5.0 at GA
    • As a developer I can honestly say I think we’ve improved processes a lot for making sure that a release doesn’t suck.
      • and as a result of this… I feel like 5.1 is the release where a lot of this stuff is fixed, and others should go a lot smoother.
    • It’s passed the dot-twenty rule for a release that doesn’t annoy you.

There are a lot of things looking good and being done right too (or if not right, a lot better than a year or two ago). e.g.

  • NDB -telco (Carrier Grade Edition) releases
  • worklog (open to the wider web)
  • forge
  • bugs db
  • commits, code reviews and all that

Things we should fix with commits, code review and all that:

  • drop the commits list all together except for crazy people.
  • everything posted to internals@lists for review, and reviews take place there
    • or IRC or whatever… but outcome posted there
    • hrrm… i should make people do that to get me to review things… (i.e. i should listen to myself)

Things we should fix internally:

  • We should have 20% time… if only for random MySQL related things… lots of cool stuff has come out of engineers just hacking… even when we weren’t 100% meant to.

Things I don’t think will happen but could be useful…:

  • dropping commercially licensed product
    • It would be really nice to use  GPL licensed libraries around the place instead of either having #ifdef or reinventing the wheel.

What if it all goes proprietary:

  • Some people speculate this could happen. Well, what then happens is a crapload of engineers leave the company – and not on good terms. So at least unlikely to happen without a massive implosion.
  • I’ll say it here: if the code I’m writing isn’t available under the GPL (or other good free software license), I’m looking for work (and you should contact me with offers).

My thoughts on the non-free Network Monitoring and Advisory Service:

  • It’s not free software… so really isn’t interesting to me personally.
  • Others see it differently and attach value to it – good for them. I hear it makes us money as well – which does keep me in adequate supplies of scotch.
  • I have used it a bit and it is quite neat – so hats off for a neat product.

P.S. there’s nothing here I wouldn’t say to anybody… and they’re welcome to disagree (and they do… sometimes even for good reasons).