List:Packagers« Previous MessageNext Message »
From:Robin H. Johnson Date:September 19 2007 12:26pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
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?

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

>> 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@stripped
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Attachment: [application/pgp-signature]
Thread
Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson10 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe10 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
          • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole20 Sep
              • Re: Distro packaging decisions and the non-public Enterprise sourceJoerg Bruehe20 Sep
            • Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole11 Sep
  • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin18 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles18 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceRobin H. Johnson19 Sep
        • Re: Distro packaging decisions and the non-public Enterprise sourceMichael Shigorin19 Sep
    • Re: Distro packaging decisions and the non-public Enterprise sourceJeremy Cole19 Sep
      • Re: Distro packaging decisions and the non-public Enterprise sourceColin Charles19 Sep
Re: Distro packaging decisions and the non-public Enterprise sourceCristian Gafton21 Sep