Last year Morgan Tocker published a graph of all MySQL forks when preparing course material on the topic. I've been preparing some material for Monty's keynote at the O'Reilly MySQL conference, and briefly touch the same topic so I have pictures too:
I don't want to be a spoiler so I'll save the narrative until after the conference. But as you see these pictures are MariaDB centric in that they make the point that MariaDB includes most of the other stuff out there (all but Drizzle). I couldn't figure out how to make that point with everything in one image, so I made it a 2 step animation.
See you in Santa Clara soon!
- Add new comment
- 26711 views
A couple of revisions
Ebay's work went into Drizzle (though we are likely to replace that engine soon). MariaDB is a subset of the MySQL branches, you aren't pulling in everything (which is sane, there is a lot crap in that tree no one wants).
One note about Drizzle's ancestor 6.0, we ripped out almost all of it in the end. There is a reason why it was a dead tree :)
Patches in and out
Yeah, I actually had to go and check your old blog where you announced Drizzle, but it said 6.0 so that's what I went with. In MariaDB we are now doing the opposite. Igor, Sergey P and Timour are pulling back the unfinished features from 6.0, putting in some months of work and in MariaDB 5.3 we will finally have the fast subqueries and complex joins that I have already been selling to customers when at Sun :-)
As for the "Abandoned patches", they are everywhere. There is no way to draw arrows from every place to every other place. You can have Drizzle+PBXT too.
Apart from having a large MariaDB logo on it?
This is not informative.
The amount of patches MySQL main branch receives daily covers all the forks taken together. On the map, though, you list all the little forks and companies here and there.
MySQL vs other forks
It is clear that MySQL is the "mother branch" of all the other forks and the first picture is supposed to even deliver that message. The work done inside Oracle is not intended to be seen as insignificant.
But, since the other forks base their work on a recent MySQL version plus add more patches that don't exist in MySQL, it logically follows that MySQL has the least patches, even if the amount of work done (in man-hours at least) is bigger than the others combined. So reading your opinion literally, I don't agree with it.
I agree with Kostja. The best patch is the one I don't have to write. MySQL has been very good at fixing my bug reports and feature requests. Now I don't to write patches for those things, MySQL is more active and my patch set is smaller.
But that's what I'm trying to say. Even if MySQL is good, and includes your patches, the Facebook branch is still MySQL + new FB patches. The FB patchset may be small in comparison to what you take from the base MySQL branch, but taken together they are still a superset.
(Btw, as I chatted with Domas on IRC too: MySQL@Facebook isn't mentioned because I see it more as a source code branch - what patches used to be - than a fork intended for end users. On the other hand it is also not an abandoned patch, so couldn't list it in that cloud either.)
are patches supersets?
I am wary of claiming that patches, branches or forks are supersets unless that includes the good (new features, better performance) and the bad (new bugs). I am also wary of claiming that something is much better until that claim is also made by real-world workloads and the new software runs in production.
Note that I just received a MySQL error while posting this (MySQL server has gone away query). Which fork are you running?
more is not same as better
So the above map is supposed to explain the relationships of forks in a "this includes stuff from that" manner. But it doesn't say "this" is better than "that", except for those who mainly like more features (or performance, which as Mårten always said, is a feature).
I'm well aware that you and many other database users are conservative and think that "more stuff" is at least suspicious, if not undesirable. This seems to also be why there is demand for the new Percona XtraDB Server, it has some of the Percona/XtraDB improvements, but not as much deviation from MySQL 5.1 as MariaDB has.
We should measure that. I
We should measure that. I don't believe that the main tree gets all that many patches. There is a lot of abandoned work, I am betting once you remove that, that very little gets in.
Metrics would be great. I can only go on the activity for bugs and feature requests that I file. They have been very active on those and that includes commits that are in 5.1 and 5.5.
Suspicion of new software is practical not conservative. Anyone who isn't suspicious of changes has never run complex system software in production.
With respect to 'more is better' lots of claims have been made elsewhere that MariaDB is a better MySQL. Don't tell me, show me.
Add new comment