Am Dienstag, 28. März 2017, 19:07:26 CEST schrieb Richard Brown:
I would like to take this point in the thread to
theoretical, thought experiment.
I want to make something absolutely clear, I'm asking the below as
'Richard the contributor', not 'Richard the SUSE employee', and what
am about to suggest should not be taken as an indication that SUSE
are even considering the below.
Similar disclaimer from me - nothing I say below is from "Christian the
Would the users and contributors on this list be
interested in a 100%
matching SLE-like LTS distribution?
Maybe ;-) - see below.
[ I never used SLE, so I only have some basic knownledge about it and
don't know all details. ]
The main difference from Leap would be
- absolutely no divergence from SLE, period
- no additional community packages in the distribution (ie. pretty
much 1 tool for 1 task. One DE, One web server)
I'm quite sure an add-on repo would pop up quickly, but let's ignore
this for a moment ;-)
- Release schedule that lags SLE (would only be able
*AFTER* SLE, whereas Leap we can develop it WITH SLE because we're
There would be no guarantee of a release-lifecycle any different from
Leap, because such an idea could rely entirely on the sources made
available to openSUSE via SUSE's contributions to Leap.
Lifecycle is an interesting point here.
Since this would basically be "SLE recompiled": I know SLE has a much
longer lifetime, and SLE customers get security updates for several
years. Would SUSE be willing to hand out those updates for free? ;-)
(In theory, it shouldn't cause much work - but I also understand that
there's a risk that some SLE customers could switch to the free
If the answer to the above is Yes the follow up
Would you like this in addition to Leap, or instead of?
My personal usecase is
- Tumbleweed on my laptop (stable releases are boring, and I hate boring
- Leap on servers (typically LAMP + mail)
If "SLE recompiled" would offer a longer lifecycle, it would replace
Leap on the servers I maintain.
I also know that lots of people use Leap on their desktop (where rock-
stable sometimes translates to "too old", and "only GNOME" would be a
nightmare for lots of people), so it should be in addition to Leap.
What use cases would you use it for which Leap
If a longer lifetime would be possible, that would be an important
feature for servers.
Minor Leap updates are not a real problem, but if I have to setup a new
server in half a year (so 42.3), I'd already know that I have to do a
major update to 43.0 within a year. I'd really prefer to avoid that on a
production server ;-)  
Would this mean reducing the scope of Leap?
Maybe in the server area (because "SLE recompiled" with a longer
lifetime would be more attractive), but in general I tend to say no.
(Don't forget mixed setups - for example, my laptop is also a LAMP
server which I use for testing stuff.)
Would you be willing to contribute to/release
maintain/support such a distribution?
If we follow your proposal to the word, the only thing we need are some
OBS machines to rebuild SLE and all updates ;-)
On a more serious note: Of course I'd maintain the packages I already
maintain in Leap and Tumbleweed. Actually the SLE AppArmor maintainer
CC'd me on more than one bug, and I help him whenever possible. Note
that "whenever possible" does not include the 2.8.x perl code - in this
case, my typical reply is "told you so" and "already fixed in 2.9+"
 For exactly that reason, I had some servers running with Leap beta
for a while. Running a beta in production can sometimes be
funny[tm] , but it's still better than doing a big update two
months later ;-)
 actually it was surprisingly boring IIRC ;-) - there were some small
issues, but no showstopper
 I can already foresee some fun when PHP5 finally goes out of support
and people finally have to update their code for PHP7...
Is a stable version of kmail planned?
[Anders Lund in https://bugs.kde.org/show_bug.cgi?id=259949#c364
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org