maria-discuss team mailing list archive

[Clint Byrum <clint@xxxxxxxxxx>]

Excerpts from Alex Yurchenko's message of Fri Feb 17 05:57:03 -0800 2012:
> Finally! A post that makes all wrong points!
> 
> On 2012-02-17 11:53, Björn Boschman wrote:
> > Hi Alex,
> >
> > Am 16.02.2012 19:33, schrieb Alex Esterkin:
> >> As an end user, I would most strongly dislike this.  You clearly 
> >> don't
> >> understand how corporate users think and operate, how they work with
> >> open source technologies, and how they plan and evolve their 
> >> technical
> >> roadmaps.
> >
> > I think I understand a bit of how corporate users think and operate.
> >
> > When you are an enterprise user who has subscribed support from MySQL
> > via Oracle you are enforced to use the Oracle binaries and cannot 
> > just
> > use the distribution supplied binaries at all.
> > This includes bugfixes and security fixes from your vendor, in this
> > case Oracle (not Debian or any other distribution).
> >
> > When you do not have such a subscription you rely on the support from
> > your distribution.
> 
> Heaven, no! Otherwise I'd still be using MySQL 5.0.something on CentOS 
> 5. And nobody wants that!
> 

Indeed, there are times to diverge from the distro, and times not to.

This gets complicated though, because there are components of the distro
that rely on libmysqlclient, and the client programs. These all start
to get ugly when your new upstream version introduces incompatible
syntax into /etc/mysql/my.cnf, or your shiny upstream version uses
/tmp/mysql.sock while old stodgy client programs use /var/run/mysql.sock.

These aren't hard problems to solve, but they're annoying things that
users have to deal with when they diverge from the distro.

> Of course, I'm relying on Oracle to provide the latest security and bug 
> fixes. Whoever wants/needs to run MySQL 5.5 has long given up on "their" 
> distribution. And, really, why/how should I rely on somebody else but 
> the vendor to fix his program?
> 

Projects like Debian and Ubuntu give users full control over their
software. While you may be in a good position to test and verify that
a large changeset from MySQL's latest version doesn't break your app,
many are not. By only introducing tiny, finite changes, the distros have
provided a very stable (as in change, not uptime) version of MySQL that
can be relied upon not to change (for better or worse) for the life of
the release.

Your statement that anybody who needs mysql will just use the upstream
mysql could use some data to support it. I don't have data that I can
share on either use case, but I can say that I have encountered users who
are grateful that they can trust 'apt-get upgrade' not to break their app.

> > That's the point this whole discussion is about.
> > Neighter Debian nor Ubuntu can offer reliable bugfixes and security
> > support.
> 
> Indeed, because, in general, they are not qualified to, and are not 
> supposed to be. Their main task should be packaging and integration of 
> software to allow painless installation and use. Key word here is 
> 'painless'. And with respect to MySQL Linux distributions don't do that 
> great of a job, because they are focusing on something they should not. 
> And while Oracle fills in for RPM-based distros, Debian/Ubuntu users are 
> on their own.
> 

Perhaps distros serve another purpose, which is to give users a single
point of contact for the support of all of the software on their system.

Debian and Ubuntu play this role, and it is in fact the more important
role than convenience of installation. For a user who has time to find
the upstream bug tracker, report bugs, and extract patches, sure, they
do not need the distro version. In a previous life, I would not have
used the distro mysql because it was a core competency. But I used the
distro postgresql, because I didn't know anything about postgresql.

For a user who has a peripheral need for MySQL, the distro version
makes a lot of sense. Perhaps they want to run Bacula and expand its
capabilities beyond what sqlite gives them. They need an avenue for
resolving their problem. The distribution serves this purpose by getting
them in contact with Bacula and MySQL interested persons. For Ubuntu,
they also have a clear path to commercial support by paying Canonical
to resolve this problem for them.

So, for Debian and Ubuntu, being able to only introduce finite change
post-release means that you can know whether or not you are faced with
a problem that you created, or one that was already present in the
upstream code.

> > Not because they don't want to.
> 
> And they better don't.
> 
> I may not understand much about corporate users thinking, but I do 
> understand a thing or two about software development. And I can tell you 
> that
> 
> 1) it takes enormous effort to fix bugs in a 3rd party software and is 
> a big waste of resources compared to the vendor doing it. Backporting 
> bugfixes may lead to side effects and require extensive testing. Why 
> duplicate efforts? Why don't you just let that 3rd party figure it out? 
> After all it is between Oracle and MySQL users.
> 

Indeed, I have wondered for a while if we are doing the wrong thing by
focusing on the idea of only introducing finite change into the system.
It has worked for a long time, but if its not possible, there are other
ways to manage the effects of change.

Perhaps we should, instead, focus on automated regression testing and
just accept the pain up front, adding regression tests as we go along.

> 2) it is _generally_ impossible to fix bugs without changing software 
> behaviour and breaking compatibility, simply because many bugs define 
> software behaviour and others may require fundamental architectural 
> and/or protocol changes. So it is totally naive to hope to stay on 
> ancient version, but keep it up to date at the same time. I really 
> appreciate stability of CentOS as a development environment, but staying 
> on the same MySQL version for 5 years is patently insane.
> 

Is the phrase "If it isn't broken, don't fix it" insane?

> 3) the whole goal is generally pointless - say, I'm running Ubuntu 
> 10.10 LTS, it has MySQL 5.1.41. If Ubuntu backports ALL fixes to it, it 
> would simply become 5.1.61. So why not just upgrade to 5.1.61 and be 
> done with it?
> 

Since the release of Ubuntu 10.04 with MySQL 5.1.41, we have backported
a few of the most critical fixes from MySQL. We would never backport
all of them. We have a firm policy of only backporting things that lack
simple workarounds or have a massive effect on the usability of a package.

Because of the opaque nature of the recent security announcements though,
it is likely that we will end up just shipping 5.1.61 into lucid though.
Its not something we really want to do, as it will challenge our ability
to support the users, but we don't have much choice.

> > Their hands are bound because
> > MySQL/Oracle somehow is not willing to provide important information
> > such as detailed changelogs or security information.
> 
> Making it nice and easy for linux distributions takes effort too. And 
> that means resources. And who's paying for that? Apparently Oracle sees 
> little value there, and I can see why: making sure that 5.1.41 gets all 
> fixes for 5 years instead of just upgrading to a newer version - nobody 
> wants that! What's the point of releasing 5.1.42, etc, then?
> 

Its not a resource issue. Oracle has a policy and they have their reasons
for sticking to it, but as far as I know, none of those reasons are
resource based.

> > This leads us to the following options:
> >  * Stay with MySQL but no security nor bugfixes
> >  * Search for an alternative which is even 100% compatible with MySQL
> > + having full community support
> 
> Or, stop playing security police and focus on what distributions are 
> supposed to do in the first place: package whatever is released and make 
> it easy for the user to install and use?
> 

See above. I do believe that distros have a much larger role to play than
convenience.

> > From my personal as well as my business perspective I want a system
> > where I can get bugfixes as well as security fixes. You should
> > consider those questions in your roadmap as well.
> 
> And that's why, as it goes now, I'll be using RPM-based Linux 
> distribution to run MySQL because there I can at least rely on Oracle to 
> do the job. And that's quite ironic as I develop on Ubuntu.
> 

You can run Oracle's static binary tarball releases on Ubuntu if you
don't like the packaged versions.