Securty are not only bug fixes which deserve to be fixed, there are others such as crash bugs or wrong query results for common queries. The bug you mentioned had Severity 5 so it of course should not go in stable release, neither Innodb performance improvements in 5.0.30

On the other hand the bug you’re mentioned went only in the enterprise version as far as I remember and was quickly pulled off with customers who downloaded it notified not to use this version.

The problem with very conservative approach is - way too long delays between version releases. For example many paying customers could not wait for 5.1 to get scaling fixes so MySQL had to go ahead.

If MySQL 5.1 would be released 6 months after 5.0 (containing say only row level replication or no new big features at all) it could be the one to contain larger bug fixes and improvements.

It’s the basis of open source.

If someone wants to patch a stable branch, you push back unless it’s a security or data loss bug or serious. Once 5.0 went STABLE, it should have seen no more work done on it that was not security or bug fixes. And this: http://bugs.mysql.com/bug.php?id=28591 does not count as a “BUG”. It was a performance enhancement. Those go into the next development version (5.1? 6.0?) No way should such a change be applied to 5.0, which is a stable branch. And if you read the release notes for each 5.0 version since it went stable, many many many of those changes are NOT Security or true bug fixes. This causes people to not trust the community versions of MySQL because they can’t be sure a simple update won’t scram their whole db server.

In using pgSQL a lot, I’ve had exactly one point release on a stable branch that introduced a bug that could affect data, and there was a point release the next week to fix it. It came and went so fast I didn’t get a chance to get bitten by it.

MySQL AB needs to stop trying to differentiate their commercial and community code right now. It’s a bad idea. When I’ve been bitten by problems in the community version, my very very last response was to think I should switch to the commercial version. My first response was to migrate off of MySQL. And there are a lot of people I know who’ve now done the same.

The sloppy approach to patching stable versions, and the idea that you can only make money selling code is gonna kill MySQL AB in the long run. I truly hope a vibrant Open Source community takes the whole thing GPL and adopts a reliable, responsible Open Source / Free development methodology around it.

The current method of upselling commercial versions feels like a protection racket or a bait and switch. yeah, that community version is ok, except for these horrible bugs. We can fix those for you for a small fee.

Sinisia, you mention that bug fixes are going through a long and elaborate process. Does this apply to all bug fixes, or just those to stable versions? I can totally understand a more involved and careful QA and reviewing process for patches to stable versions. But dev versions don’t need so much time and should be made pretty quickly, assuming they’re coming from a trusted source.

Anyway, I’ve kvetched enough. I don’t use MySQL as much as I used to, and I doubt anything MySQL AB can do will win me back. Their current course seems to be actively driving people away.

You show once again that you are very capable of getting out of the tight spots !!! During our enjoyable and interesting work in MySQL, I was wrong two or three times in five years, but you NEVER. That is OK, since you had such a great teacher. who once said: “I think I was wrong once in 1978, but I am not sure ….”. You know who said that ????

Here are my answers to your answers to my answers to your answers to ………

1) Actually, most of criticisms that we got on Community version (so I am told) is on having those bleeding edge community patches. I will say no more as I am not in direct touch with Community.

2) Microsecond patch finished to be VERY different from the original submission. It also was amended with some very nice improvements not directly related to slow query log.

3) No comment. Who introduced latency can be found scientifically, right ???? That is, aftar all, your speciality , not mine …

4) loop to point 1. (I don’t like goto);

5) You would have had a point here if 50 % of bug fixes produce new bugs. Luckily, this is not true, hence you are wrong ……. ;o) Also, Community gets last bug fixes at that point in time, so if our QA is that bad (and it is not), both versions would suffer.

6) I did not bring this point of “taking back away” in my comment, but I will will still say something. The only thing that I see that is taken away is a frequency of Community binary releases. Previous policy, in my opinion, was simply not perfect. I thought then, and I think now, that paying customers should be the ones that should get the fix sooner. Isn’t that logical ????

7) loop to point 1. (no goto’s)

Kaj responses to Mike and Jeremy posts
http://www.planetmysql.org/kaj/?p=124

Now regarding your criticism as usually you critique something I did not write

1) I’m not saying Community version will not continue. Of course MySQL is free to have some version which they call Community. I’m just saying it is pointless for my needs as I need production versions with community patches (including mine) not some version which my clients will be ready to use 2 years from now.

2) Regarding microsecond patch - 5.1 is not 5.0 (still beta). It is still taking way too much time from original submission and as I understand it is not normal community contribution process which worked well in this case but me talking to Monty at OSCON and him agreeing to personally add it.

3) I’m not showing SHOW PROFILE is implemented as it should be I’m simply stating it is only significant feature accepted for last 10 months or so. I had customers having problem with this patch, even though Jeremy tells me they are typically because of Chad’s code not his, but again this is not the point.

4) The fact your patches take too long to be merged so what ? Community tree specially had as one of its goals fast path for community patches so you could still use your new slow processes for Enterprise version. As you correctly outline it did not happen and this is exactly to the point

5) Let me clarify my point about bleeding edge. You update Community source releases 4 times per year and binaries 2 times a year (per new promise) while Enterprise binaries get Monthly rapid update packs. This means some fixes go to Enterprise version before Community version so bug fixes are first tested by Enterprise customers.
These are of course all “safe” bug fixes but as you should know from years of working in support bug fixes are never safe and there is always significant probability of fixes breaking something either directly or by side effects.

Community of course expected to get some big “bleeding edge” features.

6) Regarding your last question you put question wrong. There does not have to be differentiation in terms of software MySQL had significant revenues before these Community vs Enterprise spilt, but differentiation does typically allow you to get more sales. The problem is how MySQL does differentiation which is in many cases of “We’ll take back what we previously were giving away” rather than providing newly created extra value for enterprise customers (Merlin being exception) . May be MySQL was giving away too much ? If so why not to say so ?why to use these lame excuses “We’re doing it to better serve you”.

7) I do not deny community version remains free software I’m simply pointing out it does not matches goals of community, even those goals which were outlined by Kaj himself less than a year ago.

I read your columns 3 or 4 times so far, and all were written so well and so accurate. I am so sorry that I can’t tell the same for the above article.
Here are my criticisms. First of all, Community version will continue, but with some changes. Second, microsecond resolution for slow queries is in 5.1 already and should come out soon.

Regarding SHOW PROFILE, it turns out it has te be implemented as an option, and not as it is implemented now. I do agree partially with what you wrote on the speed with which MySQL accepts patches. But, believe it or not, new procedures are in place and even patches from us, the insiders, are going through a long, elaborate process and quality control testing.

I totally disagree with your comparison of community versus enterprise. Same holds true for comparison between Red Hat and Fedora. Red Hat is dealing mostly with software they don’t make and don’t know much about. Enterprise binaries are ones where all bugs are fixed. Enterprise binaries are NOT the ones that get any bleeding edge features. Enterprise binaries contain all fixes for the bugs made up to that moment. That is the main difference. It is actually Community binaries that have few bleeding edge features, not tested thoroughly, like SHOW PROFILE.

I also hope that you agree that there has to be a differentiation. In that way a paying customer gets more then community user. But community still gets a free software, which is also VERY important.

http://jcole.us/blog/archives/2007/08/09/mysql-community-split-officially-a-failure/