From: Rasmus Plewe (rplewe_at_suse.de)
Date: Tue Aug 07 2007 - 13:07:49 CEST
Date: Tue, 7 Aug 2007 13:07:49 +0200 From: Rasmus Plewe <rplewe@suse.de> Message-ID: <20070807110749.GA10789@coredump.suse.de> Subject: Re: [suse-sles-e] Re: SLES9 and MySQL5
On Mon, Aug 06, 2007 at 08:55:54PM -0500, Peter Van Lone wrote:
> On 8/6/07, Rainer Duffner <rainer@ultra-secure.de> wrote:
>
> > One can either:
> > - switch to a different platform, where this problem does not exist
> > (mainly FreeBSD), but other problems may (swap problems, if you want)
> > - install a new server with the new version of the enterprise OS
> > that contains all the things one wants
> > - install the 3rd party apps directly from vendor-upstream, 3rd-
> > party commercial support (MySQL, EnterpriseDB, Symas, Sernet-Samba -
> > you name it)
> > - use/create something like http://fedoraproject.org/wiki/EPEL
>
> well I think your list of choices rather echoed mine ... with the
> exception of the last item that seems like a very good idea, though I
> am sure it does not engender support from RH, and also you left out my
> "other choice" ;
>
> I still don't see why SUSE could not choose to support *a few more*
> core/key linux applications, by committing to keeping it's "still
> supported" SLES versions up to date FOR THESE SPECIFIC applications.
>
> Would that not be .... a good thing, from both the marketing angle, as
> well as for admins trying to support/enable a companies application
> developers by giving them new'ish code versions for LAMPP bits?
>
> It doesn't sound to me as though the commitment to do this would be
> huge .. though I'm not a dev so of course I don't know for sure. And I
> also realize that it MAY not be possible to update a 6 year old SLES
> to every new version of PHP ... perhaps at some point it just becomes
> impossible. To handle that, SUSE just promises best effort, to keep as
> current as possible and still offer support.
>
> Too much to ask?
That's not an easily answered question. There are lots of problems
involved.
Often, we need to do backporting and bugfixing for a package, which
means that follow-up security updates and fixes are not neccessarily
easy to do: you can't just take the fixed upstream version, package and
distribute it. We would need to support a number of e.g. MySQL versions
for SLES9, so "just" fixing a security hole in MySQL suddenly becomes
(even more) complex, potentially threatening other projects/products.
If certification is involved, it gets complicated - redoing
certifications is often not trivial.
Support is more complex, as different versions of MySQL needs to be
supported.
Testing effort grows considerably.
The problem of chosing which programs to provide version updates for has
already been mentioned.
Because of our backporting policy, often requests for a new version
really are just request for a higher version number, because relevant
features have been backported. There is a widespread "newer is better"
belief, which is not always justified...
We support the system "as it is". It was good for you and your business
when you bought it, what happened that it suddenly is not good enough
any more? Probably something in your business changed which changed your
requirements. Perhaps that also justifies to change the OS version, if
your requirements are met in the next version.
In the end, as always, it comes down to resources: Is it worth more to
you, the customer, as the added effort in engineering/maintenance/
security/testing/certification/support does cost us, the vendor?
Currently, our feeling is that those who really _can't_ change to the
next SLES version, who _can't_ buy support from another provider like
MySQL AB, who _really_ change to another distribution due to this, are
so few that on the bottom line it would be bad for our business to do
version upgrades.
This feeling may be wrong, and the best chance to influence that is
indeed the feature request feature, and making your concerns heard in
the sales/marketing/product management crowd.
Regards,
Rasmus
-- Rasmus Plewe --- Linux Beta Test Coordinator SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: suse-sles-e-unsubscribe@suse.com For additional commands, e-mail: suse-sles-e-help@suse.com
This archive was generated by hypermail 2.1.7 : Tue Aug 07 2007 - 15:11:30 CEST