Subject | Oops, we did it again (MySQL 5.1 released as GA with crashing bugs) |
---|---|
Author | Roman Rokytskyy |
Post date | 2008-11-29T23:33:39Z |
http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html
"...Here follows some of the main reasons why MySQL development
department again got a quality problem with a GA release:
# 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!
# We have changed the release model so that instead of focusing on
quality and features our release is now defined by timeliness and
features. Quality is not regarded to be that important. To quote
MÃ¥rten Mickos: "MySQL 5.1 will be release as GA in or before December
because I say so". MÃ¥rten's reasons for this is that he needs
something he can sell and a release marked "GA" is much easier to sell
than a release marked "RC".
# The MySQL core developers have been split into too many teams and
only a small part of the core developers have been working on MySQL
5.1 to get the bugs fixed. Some of the core developers have also
recently left the MySQL organization which is a serious issue as there
is not many of of them.
# 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.
# Bug fixing and development processes are not systematic and not
persistent.
# We have not been giving the MySQL community enough opportunities to
test MySQL 5.1 (too few releases). The reason few releases was made
was that if we would have done a release every month, as we have done
in the past, we would have got 14 RC releases which would have looked
silly and proved that the first RC was made too early. In addition,
the MySQL current development model doesn't in practice allow the
MySQL community to participate in the development of the MySQL server.
# The MySQL organization doesn't have a release criteria for the MySQL
server that is followed; Both the external one and the internal one
have not been followed when it comes to declaring MySQL 5.1 as GA. You
can read more about our release policy in Kaj's blog.
# Internal QA on the MySQL server was started very late in the
process. Now when the process have started to show results, the found
bugs have largely being ignored as fixing these they would delayed the
MySQL 5.1 GA date.
# The MySQL server team have a bug fixing policy where a bug that has
existed a long time has a lower priority 'because people know about
them'. This is supposedly one of the reasons why the Bug#989 mentioned
above has not been fixed..."
Sad that things go this way there... at the end this is not good to
the image of all open-source DBs.
"...Here follows some of the main reasons why MySQL development
department again got a quality problem with a GA release:
# 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!
# We have changed the release model so that instead of focusing on
quality and features our release is now defined by timeliness and
features. Quality is not regarded to be that important. To quote
MÃ¥rten Mickos: "MySQL 5.1 will be release as GA in or before December
because I say so". MÃ¥rten's reasons for this is that he needs
something he can sell and a release marked "GA" is much easier to sell
than a release marked "RC".
# The MySQL core developers have been split into too many teams and
only a small part of the core developers have been working on MySQL
5.1 to get the bugs fixed. Some of the core developers have also
recently left the MySQL organization which is a serious issue as there
is not many of of them.
# 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.
# Bug fixing and development processes are not systematic and not
persistent.
# We have not been giving the MySQL community enough opportunities to
test MySQL 5.1 (too few releases). The reason few releases was made
was that if we would have done a release every month, as we have done
in the past, we would have got 14 RC releases which would have looked
silly and proved that the first RC was made too early. In addition,
the MySQL current development model doesn't in practice allow the
MySQL community to participate in the development of the MySQL server.
# The MySQL organization doesn't have a release criteria for the MySQL
server that is followed; Both the external one and the internal one
have not been followed when it comes to declaring MySQL 5.1 as GA. You
can read more about our release policy in Kaj's blog.
# Internal QA on the MySQL server was started very late in the
process. Now when the process have started to show results, the found
bugs have largely being ignored as fixing these they would delayed the
MySQL 5.1 GA date.
# The MySQL server team have a bug fixing policy where a bug that has
existed a long time has a lower priority 'because people know about
them'. This is supposedly one of the reasons why the Bug#989 mentioned
above has not been fixed..."
Sad that things go this way there... at the end this is not good to
the image of all open-source DBs.