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

Hi Robin,

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.

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

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:

   http://mirror.provenscaling.com/mysql/enterprise/source/5.0/

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.

Do you need more 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

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

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
> Clue-by-four.
>
> 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 maintainers.

Regards,

Jeremy

-- 
high performance mysql consulting
www.provenscaling.com

-- 
MySQL Packagers Mailing List
For list archives: 
http://lists.mysql.com/packagers
To unsubscribe:    
http://lists.mysql.com/packagers?unsub=lists@pantek.com