Re: Distro packaging decisions and the non-public Enterprise source

On Tue, Sep 18, 2007 at 05:45:24PM +0200, Colin Charles wrote:
> If you have users on Gentoo that depend on the commercial Enterprise
> version, they can be encouraged to buy a MySQL Enterprise license. If there
> are people using MySQL Enterprise currently (dev-db/mysql), all that really
> is happening now is that they're being moved from Enterprise to Community.
> At the same time, the new ports can reflect that dev-db/mysql-community no
> longer exists

I specifically said 'Commericial enterprise users on Gentoo', as in those that already have a paid license, but for their own reasons, deploy with the Gentoo packaging of MySQL rather than the certified binaries. I am personally aware of two users that fall into this category - there may be more. Perhaps this would have been different if the initiative in the distant past to provide the MySQL binary packages in Gentoo had worked out, but GCC and glibc issues worked against it.

>> - Do we listen to the users that want bugfixes, and package the tarballs
>> from DorsalSource?
> I wouldn't do this if I were you, as a packager. After all, you will not be
> able to call it MySQL Enterprise (trademarked), and reporting bugs against
> a DorsalSource package is sub-optimal

We don't use "MySQL Enterprise" as a string even anywhere in our ebuilds. Additionally, it occurs only a very limited number of places in your tarballs. Using 5.0.48 for checking, it's in /man/mysql*, /Docs/, INSTALL*SOURCE, /debian/changelog.

The source tarball is identical to what you provide via the limited distribution methods. Again, bugs should be reported to the packager/distributor (Gentoo) first, and then escalated to MySQL AB as needed.

> Yes, this is an option. The BK free tool allows you to do this, and
> Gentoo's packaging system supports building from bitkeeper, which I'm
> guessing works really well for you

One of the other Mysql co-maintainers temporarily had a live ebuild that builds directly from the BK tree, but it's not of suitable quality for the main tree, and I won't use the actual BK client myself.

> However, when bugs show up, these are going to be harder to verify, and
> harder to fix, so the maintenance load on you, might be higher
The intend was specifically taking the same 'mysql-5.0.48' tag in BK and using that for the tarball, on the premise that if YOUR build process is sane, the tarball should be identical.

>> - Make a new package, dev-db/mysql-dorsal, retire the old dev-db/mysql,
>> and FORCE users to migrate to one of community or dorsal (such an
>> approach will NOT be popular for any distribution).
> I can imagine so, which is why, most, if not all distributions are sticking
> with MySQL Community Edition. I would encourage Gentoo, to do the same
> thing

You can't say stick to the community edition AND want us to not distribute enterprise at the same time. If there is a Gentoo user out there presently that has installed 'dev-db/mysql-5.0*', then they have one of the versions of enterprise that was distributed before this entire issue came up. Taking away "dev-db/mysql" means that they HAVE to migrate to "dev-db/mysql-community".

>
>> The Changelog for ES 5.0.48
>> (http://www.mysql.org/doc/refman/5.0/en/releasenotes-es-5-0-48.html)
>> lists fixes for issues that I'm certain I'v seen in production.
>> Migrating from an older enterprise to community seems irresponsible in
>> that regard - let along telling a client that the fix for the issue that
>> is affecting him won't be available until the next community release.
> The next community release, is at most, every quarter away, around the same
> time you see a quarterly Enterprise service pack
So in the meantime, when ES is available monthly, ES can still get fixes released 2 months before the next CS release comes out.

>> The release schedule for CS thus far has been:
>> 5.0.45 - 04 Jul 2007 (2007-185)
>> (http://mysql.bkbits.net:8080/mysql-5.0-community/?DATE=-12w..&PAGE=changes).
> Once every quarter, so by my math, thats once every 90 days. Quicker, if
> there's a security related issue

90 days from 4th July puts us at October 2nd. Barring a security issue coming up between then and now, can you say that there will be a release then, and that it will have better QA than some of the previous CS releases?

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

> We are interested in all bugs you or your users encounter in MySQL
> Community Edition

The ones before we apply the clue-by-four, or the ones afterwards? For the moment:
- there's a failure of the 'join' test on 5.0* under GCC4.2.0, that I am   70% certain GCC is at fault
- The 'mysqlclient' test likes to fail on the amd64 platform oddly.

Patches that Gentoo applies to MySQL presently (these are the ones for 5.0.48):

- -fPIC fixes for the i386 assembly.
- The error numbers in mysql-test/t/rpl_rotate_logs.test need an update.
- MySQL bug #9735 testcase disabled because of multibyte locale

>> So what do we do? Responses, kudos, flames, I want to hear it all.
> Please ship MySQL Community :-)

We do already, the matter is shipping Enterprise as well, and/or handling the migration matters (both technical and human) if we stop shipping Enterprise.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


application/pgp-signature attachment: stored