-----BEGIN PGP SIGNED MESSAGE-----
Wolfgang me preguntó si algunos de los que dejaron de usar opensuse les
interesaría ayudar en esto.
- ---------- Forwarded message ----------
Date: Tue, 30 Nov 2010 23:46:54 +0100
From: Pascal Bleser <>
Subject: [opensuse-project] openSUSE LTS
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)
Wolfgang Rosenauer (our local firefox/mozilla hero) made an interesting
post on his blog, in case you're not following
(shame on you!):
Stop here. Please read that post.
OK, here are my 0.02EUR to that.
The idea of an "openSUSE LTS" and/or "openSLES" aren't new
indeed, and I
suppose that most can remember the discussions around it some time ago.
And from here on, by "LTS", I (and Wolfgang) mean "longer than 18
There are basically two options on how to achieve that, from a technical
1) an LTS based on openSUSE
2) a rebranded SLES
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
The infrastructure provided on build.opensuse.org
would certainly come
in very handy. Especially when it'll have patch support :)
"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.
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.
Long story short, I personally believe that the only viable option is
"openSUSE LTS", but it does bring some technical challenges which
require a certain number of committed contributors working on the
I really concur with Wolfgang's idea/proposal to start off with a
server-oriented subset/core of openSUSE and try to keep that maintained
for half a year or more, and learn from that experience to see whether
we can realistically take on doing that for a longer period of time.
Ideas, (constructive) criticism? :)
(and thanks for reading so far, I know my mails are way too long)
-o) Pascal Bleser <>
-- I took the green pill
_\_v FOSDEM XI: 5 + 6 Feb 2011, http://fosdem.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
-----END PGP SIGNATURE-----