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