I apologize if my reply doesn't thread correctly, I'm actually replying
to a forwarded message, as for some reason my subscription to packagers@
got messed up.
I am owner of Proven Scaling (along with Eric Bergen) and one of the
core developers of DorsalSource (along with Solid).
> In the beginning, before the community and enterprise versions split, it
> was simple, Gentoo simply provided 'dev-db/mysql'.
> 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.
The above makes sense to me -- in fact I'd be hard-pressed to find a
reason why a user would choose mysql-community other than my own
profiling patch which was committed there (which for most users isn't a
very big carrot).
> Now that Enterprise source has gone closed (but not missing), and Gentoo
> is faced with a difficult decision.
It's more like the other way around -- it's not closed, it's missing.
But it's not really missing either. :)
> - 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.
I think this is the worst case for the user, and would hurt not only the
"commercial Enterprise users" but all users, as they then get a much
less-maintained version of MySQL with more delayed bug fixes.
> - Do we listen to the users that want bugfixes, and package the tarballs
> from DorsalSource?
> - 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).
We're actually not doing that for DorsalSource, we are using MySQL's own
tarballs exactly as they provide. In fact, since MySQL removed the
Enterprise sources from ftp.mysql.com, DorsalSource's source for the
tarballs is now a new service provided by Proven Scaling:
On mirror.provenscaling.com we are exercising our right to redistribute
the GPLed sources for MySQL Enterprise exactly as provided to Enterprise
customers. This is another option for you as a distro maintainer (and
CentOS at least is currently taking this option).
> - 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).
Given the above, this actually doesn't make much sense, since we are
using MySQL's own tarballs on DorsalSource (and mirror.ps), there is no
need to rename them.
> I originally applauded the concept behind the community/enterprise
> split, but I'm afraid that it did not pan out anywhere near as well as
> I'd hoped.
I wouldn't say that I ever applauded the split, but I had some hopes for
it, which were dashed quite spectacularly with the actual implementation
of the split, just as you.
> The Changelog for ES 5.0.48
> 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 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
This is actually pretty interesting, in that MySQL has been actually
releasing MySQL Community much more often than they claimed they would
-- their initial claim was 2 builds per year, and they did quite a lot
more than that in practice (but still not enough). They have since
revised their policy to 4 builds per year, so one should expect a build
every 90 days or so, I guess.
> 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
> So what do we do? Responses, kudos, flames, I want to hear it all.
I think you bring up a lot of interesting points as a distro maintainer,
and I'd love to see other maintainers come here and get involved --
after all, MySQL's most recent changes to the release policy and removal
of the Enterprise sources was aimed almost directly at you as distro
high performance mysql consulting