This week in OurDelta – Vol 2

This week we’ve been working on…

  • The re-jigged build system, so we have a single patched baseline source tarball that’s then used for all the different builds, as well as being available for you to download and build yourself.
  • Noarch distro rpm for all CentOS to more easily drop repo files into YUM.
  • The repo/download mirror system, it’ll be ready to go from the next build (domain/paths will change slightly). Add your name to https://bugs.launchpad.net/ourdelta/+bug/285200 if you’d like to be a mirror.
  • More documentation for existing (and new) patches. Currently WordPress mucks up the tabs when inside the docs pages, if you’re a WP guru who can fix this, please get in touch!
  • Fixing up existing and updated patches. We really don’t want new reserved words introduced, and if it’s absolutely necessary it should be documented. Likewise, any enhanced feature should be backwards compatible if it relates to (for instance) existing configuration options. This is nearly done, and then we’ll do a new 5.0 build. Other “new” patches are set for the next build after that.
  • Porting patches for 5.1. Since we don’t want you to lose any of the new features when trying 5.1, we’re porting the 5.0 patches that don’t yet have a 5.1 version. This does require some work, more volunteers are most welcome! In some cases a port will be waiting (or needs to be synced) for the work in 5.0.
  • Bugs. Arjen found a bug in MySQL’s mysqld_safe behaviour (any version since 4.0). One active community member submitted a patch very quickly. This is what happens when there’s prospect of getting a contribution included in a build reasonably quick: people feel enticed to participate. And that’s great! We now reckon the fix needs to be in my_print_defaults not mysqld_safe, but the example is still valid.
  • Grabbing the new Ubuntu 8.10 (Intrepid) images to set up build environments for it. Lots of people will stay with 8.04 LTS (Hardy) since that is a Long Term Support edition, but Intrepid is bound to be popular anyway.
  • Pondering the InnoDB recovery code. Surely this can be made faster without a major rewrite. Sure there can be rollbacks also and that’s another matter, but dealing more efficiently with the redo would make a serious difference already. Do feel free to experiment and send in your patch!

Leave a Reply