So I sometimes get asked if we funnel back bug reports or patches back to MySQL from Drizzle. Also, MariaDB adds some interest here as they are a lot closer (and indeed compatible with) to MySQL. With Drizzle, we have deviated really quite heavily from the MySQL codebase. There are still some common areas, but they’re getting rarer (especially to just directly apply a patch).
Back in June 2009, while working on Drizzle at Sun, I found a bug that I knew would affect both. The patch would even directly apply (well… close, but I made one anyway).
So the typical process of me filing a MySQL bug these days is:
- Stewart files bug
- In the next window of Sveta being awake, it’s verified.
ThisÂ happenedÂ within a really short time.
Unfortunately, what happens next isn’t nearly as awesome.
Namely, nothing. For a year.
So a year later, I filed it in launchpad for MariaDB.
So, MariaDB is gearing up for a release, it’s a relatively low priority bug (but it does have a working, correct and obvious patch), within 2 months, Monty applied it and improved the error checking around it.
So MariaDB bug 588599 is Fix Committed (June 2nd 2010 – July 20th 2010), MySQL Bug ï»¿ï»¿45377 is still Verified (July 20th 2009 – ….).
(and yes, this tends to be a general pattern I find)
But Mark says he gets things through… so yay for him.2
Pingback: Tweets that mention A tale of a bugâ€¦ | Ramblings -- Topsy.com
I wish they would publish stats on this. From my perspective they have been fixing bugs at a furious rate. Frankly, we are tired of upgrading our 5.1 branch to get the latest fixes.
I think you should have picked a bug that is relevant to most or even some MySQL users. I suspect that ARCHIVE gets little use. Given that the only access to it is a full table scan, why not just write the data directly to a file?
To Mark: stats on the fixed bugs can be easily obtained: they publish all bugs that they fix for each release. The rate is not furious at all: approximately 2-3 bugs per bug fixer per month for the last 6 months. Actually this rate always seemed to me too low.
Although I think it’s also interesting that the little things fall through the cracks. Having all the edges polished is nice too…. which has kind of been a staple of free software projects over the years… individual itches scratched and “patches welcome”.
just wonder if they really are anymore…
I stay away from the edges. I also do not run while holding sharp objects. And I tell my kids they are not allowed to get hurt. All of this makes life easier.
This post only scratches the surface. MySQL has thousands of reported bugs, and we get ~600 bugs reported every month. There are hundreds of bugs that are by all means more important that this one. And it’s never been a secret that the project is understaffed.
Marc: some stats are available at http://bugs.mysql.com/bugstats.php and http://bugs.mysql.com/tide.php
But when it’s just applying the patch? Fixing things sure, but when it’s
patch -p0 < foo.patch bzr commit -m "fix bug XXXX: blah blah" ? (and yeah, this has probably always been a problem.. which is a shame. Taking patches really does encourage people to write more of them).
> But when itâ€™s just applying the patch? Fixing things sure, but when itâ€™s
It’s not as simple as that. One need to actually spend time to understand the code he is modifying and take ownership if things break.
As for the patch, just looking that it uses malloc and a multiplier with sizeof char would send it to the bottom of my list. There are plenty other more important and interesting bugs to work on.
FWIW, this is similar to what projects that I work on occasionally. Some patch pending bugs just tend to linger if they touch some corner case or if the area is somewhat orphan or if its just plain boring.
Also, I recall that I’ve took patches from you in the past and applied them readily. Improve that patch and write a good explanation for it and I can take it too.
BTW, another trend I see is a useless discussion about triage values, severity, and whatever. If the patch is of good quality, has a test, a good description that makes sense, one of ours engineers can act on it much quickly and sidestep pointless arguing.
To Igor Babaev. You coordinated a bug team where developers did more than you claim we do. Also, you do not know how many engineers are working on a given release and how much time they spend on such work and on each bug. So, quit making impolite assumptions.
To Davi Arnaut: You probably think that you are behind a wall that prevents other people getting the info on MySQL bug fixing. That’ not the case. MySQL bug database is open and the statistics on it is open too. MySQL development trees are open as well (at least those that matter)
You know perfectly well that > 80% percent of the engineers involved in MySQL Server development continue working exclusively on bug fixing (actually more). Let’s subtract 20% of those who pushes the patches into the secret trees like mysql-next-mr-opt-backporting.
40 engineers in the Server Development – 40% makes 24 engineers working on bugs in releases. 50-60 bug fixes per releases makes 2-3 bugs per engineer per release (per month). Where’s my mistake?
Davi, trust me that I know much more that you think I know. I extract my numbers from the bug database, not from the reports of your managers.
In fact the situation in the MySQL Server development is much worse than I depict here.
You lost 70% of leaders (at least) and did not acquire anybody instead. About 50% of your optimizer fixes were so poor that it forced us either not to include them into the latest MariaDB releases altogether or to rework them significantly.
Igor, your mistake is thinking that anyone actually cares about your rumblings. Go write on the subject with respect to MariaDB, it will certainly be more interesting.
Nevertheless you do since you visit this corner.
Of course, you said that no one actually cares about etc. And my English lessons say that no one != nobody. ‘No one’ formally always requires ‘of some set’ or at least assumes ‘some set’. What set you mean here I hardly can guess. However, strictly speaking I can’t assert that you contradict yourself with your killing statement.
At the same time I can’t help mentioning that when any person comes to real non-complimentary numbers, facts it makes some of you at Oracle/MySQL pretty insulting and mean.
Forgive my ignorance, and I am not representative of all users, but I think Archive has a good home at Drizzle, the project where Brian works now, or MariaDB. At MySQL I think we have more important engines to focus on and opportunities to pursue. I won’t mind at all if Archive and Federated are no longer part of our code base.