Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

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

From: Colin Charles <colin(at)mysql.com>
Date: Wed Sep 19 2007 - 04:48:34 EDT


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.

Do you need help?X

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/

-- 
MySQL Packagers Mailing List
For list archives: 
http://lists.mysql.com/packagers
To unsubscribe:    
http://lists.mysql.com/packagers?unsub=lists@pantek.com
Received on Wed Sep 19 04:49:55 2007

This archive was generated by hypermail 2.1.8 : Sun Oct 07 2007 - 10:15:39 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library