Mailinglist Archive: opensuse-project (422 mails)

< Previous Next >
Re: [opensuse-project] openSUSE LTS
  • From: Peter Linnell <mrdocs@xxxxxxxxxxxx>
  • Date: Sat, 04 Dec 2010 20:18:53 +0100
  • Message-id: <4CFA941D.9010108@xxxxxxxxxxxx>
Some comments inline.

On 12/01/2010 12:46 AM, Greg KH wrote:
On Tue, Nov 30, 2010 at 11:46:54PM +0100, Pascal Bleser wrote:
Oh yeah, here is *that* topic again ;)
(and make sure to read Greg's post about Tumbleweed as well, as it is a
similar kind of project, even though they are diametrically opposed ;D)

They are only opposed in how it works, they both aim to solve a need
that people have for how they use Linux, so I see no objection to LTS at

With "openSUSE LTS", the idea is, as Wolfgang already explained in his
blog post, to pick up an openSUSE release when Novell (and the
community) stops supporting it, when it goes EOL, which is after 18
months as of now.
The effort can be a bit daunting, as it means keeping track of security
vulnerabilities, backport fixes for those, or possibly upgrade to a
newer version when backporting is too much work (e.g. Firefox).
That's pretty much what is being done by the SUSE Security team and us
(the community) during the lifetime of a release. But for longer and,
hence, it is also more work (the older the packages, the more work it is
to backport).
The infrastructure provided on would certainly come
in very handy. Especially when it'll have patch support :)

This is a worthy goal, but yes, it will take a lot of work. I think it
would be harder to achieve this than the other proposal.

Agreed. Not only do you need people skilled at backporting patches, but also serious regression testing.

I think here the experience of the fedroa legacy project is instructive. They were able to do the backports, but from my observation/opinion the necessary QA was lacking. That's not to criticize their efforts. Even RH people on board the infrastructure was lacking.

While I think the goal is worthy, I am concerned it could be a large consumer of effort for the limited number of people in the community skilled enough and motivated to make this really a viable option for the larger world.

"openSLES" is a totally different beast, as it means using the source
packages of a SLES release and rebrand them. The obvious advantage is
that it would most presumably be less work, as the hard work will
already have been done by the Security team and the staff at Novell that
does the SLES maintenance.
But it would also be a rogue project: Novell cannot legally prevent
anyone from doing just that as, albeit you do need a subscription to
have access to them, the updates are also available as source packages.
Nevertheless, it is not something Novell would like to see happening as
they (or at least a few people I've talked to about it) believe it could
be hurting their SLES business. While I don't personally share that
opinion, and before 100 people comment negatively on this, it is a
*fact* that no one can give any assurance or hard proof that it will not
hurt the SLES business.

No, unfortunately the evidence is mostly anecdotal. In this case we are looking for a negative proof.

Yes, we all know about CentOS, and a few know a few things about CentOS
and Redhat I won't be citing in public (but let's say that some people
who might or might not be working for Redhat have or haven't said that
they believe that CentOS is effectively helping them spreading RHEL, but
only off the record. or not.). But there are no hard facts or numbers to
give any proof or guarantee that it would be the same with an "openSLES".
And, personally, the last thing I'd want is people from Novell/SUSE
losing their job because of that.
Furthermore, Novell would clearly not be supportive of such a move, and
it's not sure whether we would be able to use resources such as
build.o.o for it.

Don't be so sure of this at all. I can't speak for anyone else here,
and I am not speaking as Novell at all, but I can tell you that if you
wish to persue this option, I will be glad to personally help you if you
run into resistance from Novell in any way for this project. It should
_not_ be anything that Novell should be resistant to having happen.

This I am really glad to read. In my opinion there is a tremendous amount of mind share to be gained for both Novell and for openSUSE to have an openSLES.

Just consider the numbers of hosting companies offering CentOS/RHEL versus SLES. I have worked with some excellent hosting companies in the US, but they are exclusively CentOS/RHEL. Finding a hosting company willing to give Tier1 support to SLES is far more difficult than RHEL.

Another example is scientific computing. An entire distro is based on CentOS and it is widely used in the top science/computer research labs all over the world.

The entire infrastructure of my work's network is entirely RHEL/CentOS because of the ease of transitioning services and apps from one to the other.

Again, personally, I think this is both the "easier" option, as well as
the better one to do.

Agreed. This eliminates a lot of duplicated effort and I think long-term is a win-win for Novell and openSUSE.

Best of luck with this,

greg k-h

I guess my question then is what does it take to push this forward with Novell?



To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups