25 messages in com.mysql.lists.packagersRe: Distro packaging decisions and th...
FromSent OnAttachments
Robin H. Johnson09 Sep 2007 22:05 
Joerg Bruehe10 Sep 2007 02:08 
Robin H. Johnson10 Sep 2007 17:33 
Michael Shigorin11 Sep 2007 05:16 
Michael Shigorin11 Sep 2007 05:22 
Jeremy Cole11 Sep 2007 09:39 
Colin Charles18 Sep 2007 08:45 
Colin Charles18 Sep 2007 08:57 
Colin Charles18 Sep 2007 09:12 
Michael Shigorin18 Sep 2007 10:15 
Michael Shigorin18 Sep 2007 10:17 
Colin Charles18 Sep 2007 14:02 
Jeremy Cole18 Sep 2007 16:17 
Jeremy Cole18 Sep 2007 16:28 
Colin Charles19 Sep 2007 01:48 
Colin Charles19 Sep 2007 01:51 
Robin H. Johnson19 Sep 2007 02:26 
Robin H. Johnson19 Sep 2007 05:25 
Robin H. Johnson19 Sep 2007 06:18 
Michael Shigorin19 Sep 2007 14:10 
Jeremy Cole20 Sep 2007 01:33 
Joerg Bruehe20 Sep 2007 02:03 
Joerg Bruehe20 Sep 2007 02:03 
Cristian Gafton20 Sep 2007 20:47 
Cristian Gafton20 Sep 2007 22:20 
Subject:Re: Distro packaging decisions and the non-public Enterprise source
From:Jeremy Cole (jer@provenscaling.com)
Date:09/20/2007 01:33:45 AM
List:com.mysql.lists.packagers

Hi Jörg,

I certainly will not disagree that an issue this basic should have been caught in internal QA, but at the same time, can you argue that having a community release out would have caught this issue before you gave the untested code to your supposedly "more stable" enterprise customers?

The basic issue is that you're asking customers to pay for the privilege of using untested code in production. I for one could never recommend that to a customer...

Regards,

Jeremy

Joerg Bruehe wrote:

Hi Jeremy, all !

Jeremy Cole wrote:

Hi Colin,

Yes, this has been brought up, and everything you've mentioned before has also been brought up. Our canned answer for this is that the internal server QA processes have improved tremendously, and there are many many test cases and an impressive test suite, hence MySQL has decided to try a "reverse Enterprise" model

Oh come on. *Just today* another incident has caught my attention which shows a lack of QA for basic things: 5.0.48 was pulled because of a stupid bug which should have been caught in basic QA.

We all (at MySQL AB) agree with your assessment: This should not have passed internal tests undetected, and the incident showed the test suite lacks coverage.

You may be ready to call the community unnecessary for QA, but I am not.

That is a debatable issue, depending on which kind of QA you mean.

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.

What MySQL AB can not do internally is to imitate the wide variety of usage and access patterns, database designs, applications, connectors, heterogeneous environments, etc which are developed and used by the many community members.

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).

Regards, Jörg

-- high performance mysql consulting www.provenscaling.com