On Thu, 20 Sep 2007, Joerg Bruehe wrote:
> IMO, it would be a shame if MySQL AB would try to use the community for
> such basic QA - things like that InnoDB "order by ... desc" problem must
> be covered (and caught) by our internal processes.
> So IMO, MySQL AB must not rely on the community for such basic things.
[...]
> MySQL AB relies on the community for extended QA (for lack of a better
> term), and we are grateful to everybody doing this and providing us
> feedback (positive or negative).
I understand that this is not the list to debate business practices, but
your statements above make quite a few people do a double-take at your
"reverse enterprise" policy. It's been sugested that your policy aims to
convert into paying customers those who aren't currently paying. My past
years of working in the Linux enterprise space have taught me that if
somebody doesn't want to pay you money, they will find a way to not pay
you money. Concentrating on converting those users is an expensive
operation of limited yield.
Testsuites never have enough coverage. By not adhering to the "release
early, release often" process you are not protecting the community, you
are alienating it. Yes, if and when a screwy release gets out there is the
resulting pain of the brown paper bag to go with it. That usually is a
very fair tradeoff for the lesson learned of how not do repeat that
failure in the future.
Most of the major distributions do have a development/unstable/bleeding
edge branch where things get rebuilt and upgraded to the latest and
greatest release on an almost nightly bassis. What is surprizing to a lot
of people is the number of users who like living on the bleeding edge and
provide instantaneous feedback when someting doesn't look right. By not
actively participating in that process I think MySQL is missing out big
time on some of the best release engineering QA available anywere, period.
Cristian
--
Cristian Gafton
rPath, Inc.