[sles-beta] Antwort: Re: Old freeradius-server 2.1.1

Thu Feb 28 18:14:17 MST 2013

Hello Greg and all,

On 2013-02-28 T 23:35 +0000 Greg.Lehmann at csiro.au wrote:

> Customers (me for instance) are also saying they don't
> want the effort of applying SPs within 6 months of
> them coming out. SuSE could learn a lot from the
> Ubuntu model which lets you have the cool features
> options if you really must and the stability LTS
> releases that don't need to be touched for 5 years
> (except for patches of course.)

I am afraid, I can not fully correlate the 6 months
overlap question to your Ubuntu comparison. Anyway.

SUSE offers up to 10 years support per Major Release and
up to 5 years support per Service Pack, depending on
customer needs.

Our Service Packs deliver, and Kai detailed on that, a
balance between stability, hardware enablement and
innovation beyond hardware enablement.

In that triangle, not breaking existing ISV certifications
is a key requirement for Service Packs, specifically as
SUSE Linux Enterprise is leading with respect to ISV
certifications among Enterprise Linux distributions.  In
that context it might be interesting for you to monitor
our Oracle certification for SUSE Linux Enterprise 11: we
achieved the certification for SLES 11, kept it with SP1
and also kept it for SP2, all by performing the necessary
Oracle testsuite. In fact, we achieved the "ok" for SLES
11 SP2 before our biggest competitor achieved the first
certification for his latest product major release. In my
view, this nicely shows that we kept ABI stability on the
ISV level, as required by our own rules for Service Packs.

Second. Hardware enablement is significantly driven by our
partners -- that's those guys, where you buy servers, or
who produce the internals of your servers. Don't believe
that we accept all their ideas: We don't. And I don't
share a big secret, when I state that nevertheless about
60% of all implemented features for our Service Packs come
from this one topic: hardware enablement.

The third aspect is what I called "innovation beyond
hardware enablement". Here indeed we often follow your
direct input and requests, balanced by two parameters:
* backward compatibility 
* general interest of a feature or functionality
A lot of work in the area of IPv6 enablement or
NFS improvements have been done here for example.

Now let's come back to the two topics discussed here
controversially:

1. This Thread started with an upgrade request for
   the "freeradius-server". Now, unfortunately the
   request was only for the version, and did not 
   cover detailed information about concrete issues
   in a given customer environment. 
   Please mind: I am not talking about long lists of
   bugfixes or features listed on the freeradius
   website. I am really talking about your concrete
   issues.

   I just checked our internal Feature- and Bug-Databases, 
   and I could not find any feature request, nor is there
   any outstanding bug (those would be solved via a patch).

   Why should we trigger a version upgrade?

2. In contrast I hear voices that our Service Packs would
   not be optimized for stability, and would not guarantee
   compatibility, most often in the context of the
   Kernel version upgrade for SUSE Linux Enterprise 11 SP2.

   I am afraid, I disagree.

   About 18 months ago, Olaf Kirch explained as part of
   a Beta presentation for SUSE Linux Enterprise 11 SP2,
   why the Kernel version upgrade to Kernel 3.0 improves
   quality, stability, and how we manage to not violate
   backward compatibility. The session is available online:

	http://www.novell.com/huddle/event/index.php?event_id=64e761813f83dfc86fa1c6e0da5510c3

   That said, I am well aware that a number of you have
   run into issues -- most often those who work with
   non-open-source kernel modules. We are working with
   the respective partners (some also here in this
   community) to improve our common processes and thus
   the time to market.

Summarizing, indeed, defining a Service Pack is always a
balance -- between rules, goals and forces, which live in
1300+ impersonal feature requests and even more personal
interaction. Such as this discussion.  --  Thanks!

so long -
	MgE

> > -----Original Message-----
> > From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-
> > bounces at lists.suse.com] On Behalf Of Kai Dupke
> > Sent: Thursday, 28 February 2013 7:22 PM
> > To: sles-beta at lists.suse.com
> > Subject: Re: [sles-beta] Antwort: Re: Old freeradius-server 2.1.1
> > 
> > On 02/28/2013 09:56 AM, martin.z.ziegler at daimler.com wrote:
> > > So a consistent message "SPs include cool new features" or "SPs are
> > > optimized for stability and are very conservative" would be very
> > helpful.
> > 
> > You're absolutely right, and the customers answer on what they want
> > would be 'very cool features, not breaking anything but providing the
> > newest stuff, in a conservative way', right?
> > 
> > The generic goal is to keep stuff stable, on the other side there is
> > demand for the one or the other change. In such cases we have to
> > balance
> > between various areas: resources, benefits, impact on existing
> > installation, version update or backport, enterprise readiness.
> > 
> > Some of this is not obvious at the first glance and might differ
> > depending on the concrete scenario.
> > 
> > Depending on the concrete package it might be any single or all of the
> > above listed.
> > 
> > On the other side we do the backports to support you and other
> > customers. If you handle an SP like a major release then having less
> > packages updated you have less packages to check dependencies on, but
> > still have the option to use new features if backported.
> > 
> > greetings
> > Kai Dupke
> > Senior Product Manager
> > Server Product Line
> > --
> > Phone:  +49-(0)5102-9310828     Mail: kai.dupke at suse.com
> > Mobile: +49-(0)173-5876766      WWW:  www.suse.com
> > 
> > SUSE Linux Products GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG
> > Nurnberg)

-- 
Matthias G. Eckermann     Senior Product Manager   SUSE® Linux Enterprise
SUSE LINUX Products GmbH  Maxfeldstraße 5          90409 Nürnberg Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)