List:Packagers« Previous MessageNext Message »
From:Colin Charles Date:September 18 2007 3:45pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
Robin H. Johnson wrote:

Hi!

> While I don't see any previous traffic on the matter, it's exactly
> what's intended for this list I believe. I'd love to hear from both
> MySQL folk as well as other distro packagers on the matter.

This is the perfect list for such a discussion. Some package maintainers 
had previous discussions via email, i.e. before this decision was made, 
so we got to hear them out, take copious notes and comments, and of 
course, now we'd like to live up to our promises

> I'm the Gentoo package mantainer for MySQL (I started the Gentoo MySQL
> herd, and it temporarily had two other maintainers, but I'm back doing
> it now again). I've been using MySQL for nearly 8 years - I applied for
> and was granted an educational use license (3.20-3.22) before MySQL went
> GPL. I was also one of the phpMyAdmin developers, now retired from that
> project. Additionally, work with MySQL is an important part of my
> salaried job as well as my consulting.

I'm glad you are active in the MySQL community!

> Then the split happened, and we added 'dev-db/mysql-community' to the
> tree, while the main 'dev-db/mysql' followed the Enterprise source
> releases. This allowed folk to just upgrade into the enterprise version,
> which had better support in terms of bug-fixes actually getting out to
> users than the Community version.
> 
> Now that Enterprise source has gone closed (but not missing), and Gentoo
> is faced with a difficult decision. 
> - Do we respect the wishes of MySQL AB, and only package the community
>   sources, dropping ES entirely? This would hurt any commercial
>   Enterprise users on Gentoo.

This would certainly be the ideal situation, from a distribution perspective

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

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

However, if you really feel that dev-db/mysql-dorsalsource is an option, 
for your users, there is nothing anyone can do to stop you from doing so

> - We could do what Dorsal is doing in simply waiting until the MySQL
>   developers tag the release in BitKeeper, and roll our own tarballs
>   (Gentoo already does this for some other upstream codebases).

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

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

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

> 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

If you have better ideas to support differentiation, I would gladly hear 
them out, even via private emai

> The release schedule for CS thus far has been:
> 5.0.45 - 04 Jul 2007 (2007-185)
> = 64 days
> 5.0.41 - 01 May 2007 (2007-121)
> = 63 days
> 5.0.37 - 27 Feb 2007 (2007-058)
> = 49 days
> 5.0.33 - 09 Jan 2007 (2007-009)
> = 80 days
> 5.0.27 - 21 Oct 2006 (2006-294)
> Average of 64 days between releases, however 67 days have passed since
> the last community release, and I don't know when the next community
> release will be. The BK commitlog shows nothing for the last 10 weeks
> (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

> Distros are also in an interesting position, that we expect users to
> report bugs to us before taking them to the upstream (some upstream
> projects won't even take bug reports from Joe Random Gentoo User - they
> want it to come from a Gentoo Developer after it's been verified). This
> is intended to weed out problems with how the distro has packaged MySQL,
> as well as users with broken systems (bad RAM/PSU turns up far too often
> in Gentoo) and those that need a little helping hand with a
> Clue-by-four.

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

> So what do we do? Responses, kudos, flames, I want to hear it all.

Please ship MySQL Community :-)

	hope this helps
(and I'm happy to continue discussions, to explain things further)


-- 
Colin Charles, Community Relations Manager, APAC
MySQL AB, Melbourne, Australia, www.mysql.com
Mobile: +614 12 593 292 / Ekiga/Skype/Gizmo: colincharles
Web: http://www.bytebot.net/blog/

MySQL Forge: http://forge.mysql.com/
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