The MySQL development team decided to celebrate the (US) Thanksgiving
holiday with the release of
, the first "general availability" (read "production-ready")
release in the 5.1 series. There is a lot of good stuff in 5.1.30,
including table partitioning, row-based replication, a new plugin API, a
built-in job scheduler, and more; see the
for more information. It's a celebration point for a
long development series; the MySQL developers are to be congratulated for
what they have accomplished with this release.
Behind the celebration, though, one can hear the grumbling from unhappy
developers and users. This release has been a long time in coming; the
first 5.0 GA release was in October, 2005 - just over three years ago. The
first 5.1 release candidate (5.1.22) came out in September,
2007; seven more "release candidates," many with major changes, were
announced over the following 14 months. So the 5.1 production release
came rather later than desired, but some developers feel that it was still to
soon; the complaints reached a climax in this
lengthy posting from Michael "Monty" Widenius, the original creator of
MySQL. His point of view, in short, is that this release has fatal bugs,
and that these bugs come from a number of flaws in how MySQL development is
Your editor cannot claim to be an expert on the MySQL development
community. But Monty, presumably, is an expert on this community,
so his observations have a higher than usual likelihood of reflecting
something close to reality. Reading various dissenting posts (example)
has done little to make your editor feel otherwise.
And, in any case, much of what Monty says rings true when compared against
experiences from elsewhere in the free software community. As projects
grow, they must occasionally revisit their development models. There is
little happening here which is truly unique to MySQL.
MySQL 5.1 was declared beta and RC way too early. The reason MySQL
5.1 was declared RC was not because we thought it was close to
being GA, but because the MySQL manager in charge *wanted to get
more people testing MySQL 5.1*. This didn't however help much,
which is proved by the fact that it has taken us 14 months and 7
RC's before we could do the current "GA". This caused problems for
developers as MySQL developers have not been able to do any larger
changes in the source code since February 2006!
Two things jump out of that statement. One is that MySQL apparently
suffers from an inadequate testing community. Needless to say, that
is not a problem which is unique to this project; testing is a scarce
resource throughout our community. MySQL users who are unhappy with the
results of the development process might want to ask themselves if they are
doing enough to help with the testing process. Like it or not, testing
software and finding bugs is one of the costs of "free" (beer) software.
If this testing doesn't happen during the development cycle, it will end up
happening with the "stable" releases instead.
The other attention-getter above is the statement that MySQL developers
have been unable to make major changes since early 2006. One need only
think back to the 2.4 kernel days to see the kind of damage that can result
from pent up "patch pressure." Developers get frustrated, major changes
start to find their way into "release candidate" code, and the number of
bugs tends to increase. The existence of a separate MySQL 6
development branch helps, perhaps, in reducing patch pressure, but it can
also only serve to distract developers from stabilizing current release
Related to this is another assertion:
Too many new developers without a thorough knowledge of the server
have been put on the product trying to fix bugs. This in combined
with a failing review process have introduced of a lot new bugs
while trying to fix old bugs.
Review would appear to be a big part of the problem in general. It may
well be that a failure of review has caused the introduction of new bugs
with fixes. But one could argue that the problem is deeper than that: any
code which failed to stabilize over fourteen months of release candidates
should, almost certainly, never have been merged into the MySQL trunk to begin
with. It seems that there are not enough eyeballs being applied to major
new features before they go in.
Your editor has resisted the temptation to
make comparisons with other relational database manager projects, but
there is value in comparing this state of affairs with the review problems faced by
PostgreSQL in recent years. An inability to get additions to
reviewed resulted in those additions not being merged. That, in turn,
leads to delayed releases with fewer than the desired number of features,
neither of which is particularly pleasing for users or developers. But, on
the other hand, PostgreSQL does not appear to have the same kind of trouble
stabilizing its major releases.
Perhaps the key point to take away from all of this, though, is here:
In addition, the MySQL current development model doesn't in
practice allow the MySQL community to participate in the
development of the MySQL server.
MySQL is very much a corporate-owned, corporate-driven project, and it has
been for a long time. Decisions on what to include are made internally;
there is little discussion of development decisions on the project's
mailing lists. It is hard to find information on how to contribute to the
of the available information still tells prospective contributors to
use BitKeeper. All code is copyrighted by MySQL (now Sun), which reserves
(and uses) a right to distribute that code under proprietary licenses.
All of the above reflects an arrangement which has worked well for years,
and which has produced an immensely valuable database manager used
by vast numbers of people. But it is not a community
project, so development decisions will not necessarily reflect the best
interests of the wider user or developer communities. If, as Monty suggests,
those decisions are made in ways which favor features and deadlines over
quality, there will be little that the community can do about it.
to post comments)