Weekly Edition
Return to the Development page
| |||||||||||||
Monty on MySQL 5.1
Here's an interesting, detailed posting from Michael "Monty" Widenius on the problematic MySQL 5.1 release. "So what went wrong with MySQL 5.1?
This is surprisingly not because our developers don't do a good job. On the contrary we have an excellent dedicated team of developers that are very good in what they are doing. However, even an excellent team can't work if the conditions are not right."
(Log in to post comments)
Monty on MySQL 5.1 Posted Dec 1, 2008 19:59 UTC (Mon) by pboddie (subscriber, #50784) [Link] If you are using MySQL 5.1 just as a 'better' version of MySQL 5.0 I'm using PostgreSQL 8.x as a 'better' version of MySQL 5.0 and don't experience the kind of problems Monty describes. Meanwhile, if you want a major cause of Monty's headache, look no further than this: We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Yes, the S&M (sales and marketing) "time-based release" model which requires a long slog by the developers, lip-service to quality by management, and pixies sprinkling their magic dust at the last minute. Still, I've had conversations with Oracle people in the past where they've more or less warned people off using the new features in their database system, so perhaps MySQL-the-organisation are just warming to their new role in the world of commercial database vendors.
Monty on MySQL 5.1 Posted Dec 1, 2008 21:45 UTC (Mon) by sbergman27 (guest, #10767) [Link]
I disagree that time-based releases are bad. With good project planning and management, it can work quite well. That means keeping the new feature list reasonable, being able to say "No" when required, a willingness to drop features that just aren't really ready in time, and reasonable flexibility in delaying the release some *if* that becomes necessary due to some unforseen, last minute problem. Time-based releases actually encourage good, agile development practices. Obviously, they can also be a disaster if the project leader, BDFL, or whomever doesn't handle it right.
I felt like the really disturbing bit from the article was:
"""
You might recognize the old "present it as more stable than it is to trick people into testing for us" technique. Although this is not the worst example. Some well known FOSS projects actually release alpha quality code as GA.
Monty on MySQL 5.1 Posted Dec 1, 2008 22:47 UTC (Mon) by nix (subscriber, #2304) [Link]
This isn't desktop software, though. Databases are kind of special, like
filesystems: a huge variety of bugs in them can be data-loss bugs, and when you lose data you can lose a *lot* at once.
As such, the priority must *always* be quality, specifically
(PostgreSQL gets this right: note their massive backports of any data loss
Monty on MySQL 5.1 Posted Dec 1, 2008 23:10 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
quality and time-based releases do not need to be exclusive.
using your example, Postgres does time-based releases, but they also do a very good job of policing what features go into each release.
time based releases are a problem when the emphisis is on the release schedule and the feature checklist (with quality dropping off if nessasary). if the emphisis is on the release schedule and quality (with features being allowed to drop off if they aren't ready) it's not a problem.
Monty on MySQL 5.1 Posted Dec 1, 2008 23:48 UTC (Mon) by pboddie (subscriber, #50784) [Link] time based releases are a problem when the emphisis is on the release schedule and the feature checklist (with quality dropping off if nessasary). This can also be phrased as "time-based releases are a problem if there's a product marketing/strategy department in the picture". Mostly because arguments about what goes in and what stays out are much harder to resolve when a bunch of people are whining that "they promised something to [impress] a customer".
Monty on MySQL 5.1 Posted Dec 2, 2008 0:10 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
yes and no.
it depends on who is in charge.
if it's marketing the feature list and time schedule are paramount, everything else must adapt.
if it's not marketing the business can still make the choice between
1. deploying the feature on time but at poor quality.
2. deploying the feature late, but with good quality
3. deploying on time with good quality, but dropping the feature until next time.
one very good thing about time based releases is that you have a pretty good idea what "next time" is, and if it's a relativly short cycle it's not that big a deal to drop the feature for one cycle. If your cycles are unpredictable, it becomes a very big deal to drop a feature (because you don't know how many years it may be before that feature becomes available)
In general I'm a big fan of having fairly frequent time-based releases, but you do need to be aware of the trap that marketing people will try to push you into and avoid it.
Monty on MySQL 5.1 Posted Dec 2, 2008 8:29 UTC (Tue) by drag (subscriber, #31333) [Link]
The reality of the situation is that a buggy time-based release is much more valuable to end users then a stable release that doesn't exist. Software that doesn't exist isn't going to help anybody else.
see also: Debian
The correct approach is to get a stable release on a timely basis. Features be damned. As long as you meet the minimal requirements to get the job done then that's what is most important.. anything else your able to accomplish is gravy.
One of the things that free software folks suffer from is the inability to get their egos out of the way and concentrate on getting minimal functionality _correct_ first, then move onto fancy features next. Instead the tendency is to get basic functionality down first then move onto fancy features while hopping the broken-in-small-ways basic functionality stuff solves itself as time goes by.
Of course, like you guys alluded to the marketing folks push on features first on a time-based basis. Which is a trap of a different, but equally destructive, nature.
Monty on MySQL 5.1 Posted Dec 2, 2008 7:55 UTC (Tue) by nix (subscriber, #2304) [Link]
That is, note PostgreSQL's massive backports of any data-loss bug *fix*.
Oops.
Nobody is perfect, but... Posted Dec 2, 2008 9:09 UTC (Tue) by khim (subscriber, #9252) [Link] That is, note PostgreSQL's massive backports of any data-loss bug *fix*. It's one thing to port fix for previously unknown data-loss bug, it's totally different thing to declare thing as stable when it contains known data-loss bugs. I like MySQL but this latest trend of adding pile of features without proper testing is quite worrysome.
Monty on MySQL 5.1 Posted Dec 2, 2008 13:47 UTC (Tue) by flewellyn (subscriber, #5047) [Link] I'm using PostgreSQL 8.x as a 'better' version of MySQL 5.0 Ouch. :-) That was mean. Apt, but mean. I have to wonder, though, if one of MySQL's problems is the plethora of storage engines it can use. I can see how some might consider this an advantage, mind you. Flexibility! Configurability! Adjust the storage engine to your needs! And it's so pluggable and hackable! But, this approach, while it works for some things, is a really bad idea with something as fundamental to a DBMS as the storage engine. It badly breaks the abstraction of the DBMS over the underlying storage. It requires database administrators to make decisions about the kind of access patterns and data models a table will have in advance, when this may not be known. And some of the tradeoffs that the various storage engines make are really unacceptable, such as not supporting transactions for MyISAM or Falcon. PostgreSQL, on the other hand, has one storage engine. It works very well, gives great performance, it's still quite configurable, at no point does it sacrifice ACID compliance in the name of speed (that's determined by transaction isolation levels or locking, like a DBMS should), and most importantly for something so fundamental, it's invisible. There's no good reason for a database admin to have to worry about storage engines. I'm reminded of the CPU scheduler issue in Linux, where Linus (rightly, I think) insisted on having one good scheduler, that does the right thing in almost all cases, and is tuneable for the cases where its performance is suboptimal, as opposed to having a variety of soso schedulers which work well only in narrow cases and require more advance planning to use. MySQL might be better off if they had just decided to make one storage engine that was really good, rather than going down the deceptively cool but wrong "plug in what you like" path for something so critical to a DBMS.
Monty on MySQL 5.1 Posted Dec 2, 2008 22:48 UTC (Tue) by epa (subscriber, #39769) [Link] Amen to that. Far better to have one storage engine that just works than a wide choice of engines all broken in different interesting ways. This is an example of what Linux Hater called the fallacy of choice.
Monty on MySQL 5.1 Posted Dec 3, 2008 2:51 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Eh, I think Linux Hater is overstating it, and his choice of LAMP as an example of a "get it right" stack is ironic, given that it's the M in LAMP that we're criticizing here.
I think having lots of choices works fine in many contexts. It's just that, in this case, a DBMS's storage engine is something that needs to work well in many cases, and having choices is harmful to that goal.
PostgreSQL offers many choices, in other contexts: you can add your own types and operators, extension packages, and even procedural language handlers, so that you can write database functions in the language of your choice. The difference here is that the choices are built on top of a solid foundation in which the basics "just work".
Monty on MySQL 5.1 Posted Dec 2, 2008 0:22 UTC (Tue) by briangmaddox (subscriber, #39279) [Link]
It also doesn't help when you're spreading all your resources on keeping version 5 up to date, working on 5.1, working on 6.0, Maria, and also keeping separate sub-trees for things like experimenting with OGC conformance and so on. I think their biggest problem is that they're doing way too much at a time. Thus it takes forever to get anything done and when they do a release, it has problems like we see here.
I think the whole project hasn't figured out if they want stability or shiny new features. Some consolidation and focus would be a good thing.
|
|||||||||||||