List:Packagers« Previous MessageNext Message »
From:Colin Charles Date:September 18 2007 4:12pm
Subject:Re: Distro packaging decisions and the non-public Enterprise source
View as plain text  
Jeremy Cole wrote:

Hi!

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

There are obviously more planned features, besides your own profiling 
patch. I believe the patch queue log is public, even

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

Its still GPLv2, and its not closed source. So tarballs are available 
only to Enterprise customers, via enterprise.mysql.com

Sources are still open, via Bitkeeper

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

Since distributions don't normally *ship* every month, how does this 
make it worse for our user base?

Distributions typically ship once every 6-9 months, with the exception 
of Gentoo and FreeBSD who have a different sort of packaging system that 
handles "ports"

So, frankly, every bit of software you get on your distribution is 
mostly *outdated*. Providing one source release once every 3 months (90 
days) ensures that distributions are actually getting the freshest copy 
of MySQL Community, and during their "support cycle" can release another 
update in another 3 months, even


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

Yes, there is. I believe you cannot call it MySQL Enterprise, because 
that in itself is trademarked

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

Now its 4 source tarballs a year, so every quarter, i.e. 90 days

This is meant to *help* distributions (though I can see this being 
negative towards Gentoo or FreeBSD whom have no "release" concept - 
everything is latest)


	thanks and kind regards

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