List:Packagers« Previous MessageNext Message »
From:Jeremy Cole Date:September 11 2007 4:40pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
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.

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.

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