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

Hi!

>> There are obviously more planned features, besides your own profiling 
>> patch. I believe the patch queue log is public, even
> 
> Huh?  How can that even be true given the recent announcement of 
> "nothing new in 5.0" and discussion of the failure of the split?  My 
> understanding (from Kaj's posts) is that there will be nothing new at 
> all in 5.0-community, meaning the only difference henceforth will be 
> release frequency.

Yes, consider this reasoning as something for 5+1. No new features, is a 
crucial item for stability :)

Must think ahead for the future. 5.0 has gone thru too many changes, and 
I think we shouldn't beat the horse on it any longer...

>> Since distributions don't normally *ship* every month, how does this 
>> make it worse for our user base?
> 
> Mainly because there is now a highly artificial delay in getting bug 
> fixes out to normal users.  Why should a distro maintainer put up with 
> that artificial delay?

The artificial delay works towards *most* distro maintainers benefit. 
They don't release updates daily or monthly ;-)

>> 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
> 
> This all assumes that MySQL is stable.  Note that 5.0 has proven to be 
> not so stable.  Anyone on 5.0 has been upgrading quite often to fix 
> stupid bugs, unless they're on 5.0.27 (which has been the most stable 
> release in recent history).

Hence the reason for no more new features, which will help all future 
mysql releases as well

>>> 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
> 
> No, the source releases do not have enterprise in the name, that gets 
> introduced in the build process and only appears on the resulting 
> binaries.  So by distributing the source releases (called e.g. 
> mysql-5.0.48.tar.gz) it is not possible to be encroaching on the 
> enterprise trademark.

Correct. select version(); was what i was referring to more than anything

> The DorsalSource builds also take care to not use "enterprise" in the 
> name, they are merely MySQL builds with even version numbers.  You'll 
> notice that the only place "enterprise" even appears is to name the 
> "branch" from which the sources come, which I believe should be fair game.

As long as you haven't heard from legal, all must be well *grin*
-- 
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