Am 22.03.2017 um 09:59 schrieb Ludwig Nussel:

Wolfgang Rosenauer wrote:

...

Am 20.03.2017 um 17:18 schrieb Marcus Meissner:

...

Note that the openSUSE Leap 42 class of distributions is designed to be easily upgradable within minor versions, so Leap 42.1 to Leap 42.2 update should be easy and seemless.

and if they are not? That list does not look too bad but it's just for the "Upgrade" component. There may be others.

https://bugzilla.opensuse.org/buglist.cgi?classification=openSUSE&component=Upgrade%20Problems&list_id=6284328&product=openSUSE%20Distribution&query_format=advanced&resolution=---&version=Leap%2042.2

What concerns me is that almost all are NEW. At least one of them made me stop ugprading my remaining 42.1 systems at least temporarily in the hope that there might be patches coming up.

So the question is how to deal with unresponsive package maintainers?

Probably :-( I'm not saying I have a solution for that. I mean it hurts Leap's reputation and given that some affected components are rather critical especially in server environments where Leap was supposed to replace Evergreen (at least in my mind) this is a problem. For example I'm pretty sure that SLE has openldap as well. How and who would deal with that component in SLE and why is there a disconnect between SLE and Leap there? Or is there none and SLE is broken the same way? (I doubt that.) IMHO we as a project should try everything to avoid that or mitigate such situations. Unresponsive maintainers can always happen unfortunately for many reasons. Probably there are or should be a few key areas where we introduce a fallback to drive things forward? As said I do not have a solution but I would love to have Leap accepted as some kind of LTE which we still have to prove that it works. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday, 22 March 2017 18:18:20 CET Ludwig Nussel wrote:

Wolfgang Rosenauer wrote:

...

Am 22.03.2017 um 09:59 schrieb Ludwig Nussel:

...

Wolfgang Rosenauer wrote:

...

Am 20.03.2017 um 17:18 schrieb Marcus Meissner:

...

Note that the openSUSE Leap 42 class of distributions is designed to be easily upgradable within minor versions, so Leap 42.1 to Leap 42.2 update should be easy and seemless.

and if they are not? That list does not look too bad but it's just for the "Upgrade" component. There may be others.

https://bugzilla.opensuse.org/buglist.cgi?classification=openSUSE&compon ent=Upgrade%20Problems&list_id=6284328&product=openSUSE%20Distribution&q uery_format=advanced&resolution=---&version=Leap%2042.2

What concerns me is that almost all are NEW. At least one of them made me stop ugprading my remaining 42.1 systems at least temporarily in the hope that there might be patches coming up.

So the question is how to deal with unresponsive package maintainers?

Probably :-( I'm not saying I have a solution for that. I mean it hurts Leap's reputation and given that some affected components are rather critical especially in server environments where Leap was supposed to replace Evergreen (at least in my mind) this is a problem.

For example I'm pretty sure that SLE has openldap as well. How and who would deal with that component in SLE and why is there a disconnect between SLE and Leap there? Or is there none and SLE is broken the same way? (I doubt that.)

Unfortunately in this specific case I don't have records as to why we accepted the deviation :-( Nowadays the leaper bot would leave a comment and warn already.

...

IMHO we as a project should try everything to avoid that or mitigate such situations. Unresponsive maintainers can always happen unfortunately for many reasons. Probably there are or should be a few key areas where we introduce a fallback to drive things forward?

Reaching out to this list is one way. I've also pinged the SLE maintainer to take a look. Also, the upgrade tests in openQA need more attention. So far we only test updates of basically default installations but not how extra services behave.

Agreed. More community effort would be appreciated to extend the test coverage with openQA tests on that matter. I can think of the following first steps: * compare to openSUSE Tumbleweed regarding the coverage of scenarios, maybe we can simply enable some more for Leap after someone proved they work * extend the update tests to also check extra modules, like with the "extra tests" on the upgraded hard disk images * install and configure more different stuff in the base images that are then upgraded to a newer version -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il giorno Thu, 23 Mar 2017 19:15:21 +0100 Rüdiger Meier ha scritto:

We need written rules. IMO It should be really really really difficult for a package maintainer to update his package in Leap. In

If you make it too difficult, you'll have maintainers lose their interest in actually maintaining their packages in Leap. In order to properly support some upgrades (KDevelop and KDE Applications, specifically) I went out of my way with upstreams to make sure things would work without making release management too angry. Make it more difficult than this (and if you care about the distro, doing a good job is *already* difficult) and I wouldn't just bother.

Lets make an example. Let's scare away all the users and maintainers who always wants the newest stuff. Tumbleweed is made for them.

What if we ship unmaintained software? KDEPIM 4.x was kept in 42.2 to eas transitions, but we knew well in advance that it had *no* support from upstream even before the release. For 42.3 we're going to remove it. This isn't just "the newest stuff". It's ease of maintenance. (And note that Plasma will stay instead at 5.8, which is a LTS release) -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B

Il giorno Thu, 23 Mar 2017 20:28:24 +0100 Rüdiger Meier ha scritto:

Well that's what I want. There _is_nothing_ to maintain/to upgrade except fixing reported bugs (and _maybe_ adding very important features). You should fully concentrate on Tumbleweed development.

That's what we do already. But I don't want a sloppy experience for Leap users as well.

I'm still using Kdevelop3 (though not often). Later versions have no automake support anymore ...

Regardless of that, upstream is dropping 4.x support soon.

Exactly this is what should be forbidden strictly IMO. Removing packages during LTS lifetime is a no no. Otherwise Leap is just ...

Bugs against unmaintained software may not even be fixable, and we'd have to do things all on our own. Something we can't do at the moment. Unless someone is volounteering to handle the PIM 4.x bugs (because we won't be able to). And I mean in a proper way, not like KDE3.

whatever, but for sure no LTS. Please don't remove kpim4 or any other package from Leap.

Sorry, we want to keep maintenance *sane*. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B

Il giorno Thu, 23 Mar 2017 21:24:37 +0100 Rüdiger Meier ha scritto:

anymore and would not install it for our staff. I wouldn't have it accepted in Leap from the beginning.

OK, you're not helping nor willing to help. Duly noted.

like Leap will never be and not even wants to be a competitor for real LTS distros like Cent-OS, Ubuntu-LTS or Debian-LTS.

Please don't state your opinions as facts. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B

On 03/23/2017 09:19 PM, Stefan Seyfried wrote:

Am 23.03.2017 um 20:28 schrieb Rüdiger Meier:

...

Well that's what I want. There _is_nothing_ to maintain/to upgrade except fixing reported bugs (and _maybe_ adding very important features). You should fully concentrate on Tumbleweed development.

Ok, so no more bugfixes and security updates for Leap from me.

You have your wish granted.

?? Lol, you little nasty boy! My only wish was "bug fixes only". Now giving me no more bug fixes is as bad as my evil cousin was when we were kids. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/23/2017 09:37 PM, Stefan Seyfried wrote:

Am 23.03.2017 um 21:34 schrieb Rüdiger Meier:

...

Lol, you little nasty boy! My only wish was "bug fixes only". Now giving me no more bug fixes is as bad as my evil cousin was when we were kids.

So you want to force me me to backport stuff for you when upstream does no longer support the old release instead of doing the simple version update?

Sorry, for most of "my" stuff I'm not going to do that, because I simply do not have the time.

Well, upgrading fixes bugs and brings new bugs. So if you do nothing we well have neither more nor less bugs. Anyways, reproducing a bug and confirming that a newer version already fixes that bug is already the half work. Somebody else may do the rest and actually backport it. Maybe the other guy will be even a paid SLE developer (in case that we have the same package as SLE ...) BTW we both know that nothing is black or white. Upgrading "socat" from 1.7.3.0 to 1.7.3.1 is probably more safe than upgrading kde4 to 5. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 23, 2017 at 10:16:12PM +0100, Michael Ströder wrote:

Rüdiger Meier wrote:

...

Anyways, reproducing a bug and confirming that a newer version already fixes that bug is already the half work. Somebody else may do the rest and actually backport it.

Backport patches are causing nothing than grief and frustrate upstream developers.

Essentially what you are saying is that the very idea of SLES or RHEL (or any LTS distribution) is completely wrong. Sure, upstream developers would love everyone using latest released version (or even development snapshot). Users, on the other hands, are mostly not excited about continuous stream of regressions and incompatible changes in behaviour. Leap was presented as LTS-type distribution. If part of package maintainers decides to ignore that and upgrade their packages whenever they feel like it (or don't feel like backporting a fix), we get a distribution which is part LTS and part "rolling upgrades" which may end up making fans of both approaches unhappy. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-24 10:26, Felix Miata wrote:

Michal Kubecek composed on 2017-03-24 10:02 (UTC+0100):

...

Users, on the other hands, are mostly not excited about continuous stream of regressions and incompatible changes in behaviour.

+1

+2 I would love upstream developers to stop creating new features some time after a release and correct all reported and known bugs. Ie, feature freeze on all projects till all the bugs are solved, as far as possible. And then release that as a correction to the release. Being on the last release of everything is not practical. A change on something breaks something on another project because of course, they developed 'A' using the previous release of 'B'. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAljVcFUACgkQja8UbcUWM1wO2gD9EKNqpDGEzCPr2MLa164gMg4Z /HYPgszJsv13bM9gpXMA/RDvmkSaOgA1WC2FPj5waCMeXaQOKLaGNEolPAEJz5gN =7kal -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Mar 23, 2017 at 07:15:21PM +0100, Rüdiger Meier wrote:

Why don't we use SLE as is?

Actually, we do - most of it. The problem is SLE provides much fewer packages than openSUSE so that taking SLE as is wouldn't satisfy too many openSUSE users. The number of packages that exist in both but openSUSE has newer version is relatively small (higher than I would like, though).

We need written rules. IMO It should be really really really difficult for a package maintainer to update his package in Leap.

IMHO one of the big problems of today's distribution is that many people stopped distinguishing between updates and upgrades; popularity of so-called "rolling updates" distributions - which are in fact also "rolling upgrades" (which fans of the concept keep forgetting to mention) - is one of the reasons, IMHO. I don't agree that _updating_ a package in Leap should be any more difficult than it used to be in pre-Leap era. On the other hand, _upgrading_ a package between point releases (or even within one) should be IMHO always carefully thought of and well and clearly reasoned (and the reason documented). The same should IMHO apply to using newer versions of packages existing in SLE 12 SPx for Leap 42.x - and I'm not really convinced this was always the case. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 23.03.2017 um 21:03 schrieb Rüdiger Meier:

On 03/23/2017 08:33 PM, Michal Kubecek wrote:

...

Actually, we do - most of it. The problem is SLE provides much fewer packages than openSUSE so that taking SLE as is wouldn't satisfy too many openSUSE users. The number of packages that exist in both but openSUSE has newer version is relatively small (higher than I would like, though).

I don't believe this. Do you have any numbers? BTW I also count in the packages which got upgrades since 42.1.

What do you want to count exactly? I think all data is available. Just list all packages which are in SLE: osc ls SUSE:SLE-12-SP2:GA Extract the information for those packages from here: https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/00Meta/looku... Filter those which are not referring to "SUSE:SLE-12*" That is the count and the list of packages where Leap deviated for some reason from SLE. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/24/2017 01:25 PM, Ludwig Nussel wrote:

Michal Kubecek wrote:

...

On Thu, Mar 23, 2017 at 07:15:21PM +0100, Rüdiger Meier wrote:

...

Why don't we use SLE as is?

Actually, we do - most of it. The problem is SLE provides much fewer packages than openSUSE so that taking SLE as is wouldn't satisfy too many openSUSE users. The number of packages that exist in both but openSUSE has newer version is relatively small (higher than I would like, though).

...

We need written rules. IMO It should be really really really difficult for a package maintainer to update his package in Leap.

IMHO one of the big problems of today's distribution is that many people stopped distinguishing between updates and upgrades; popularity of so-called "rolling updates" distributions - which are in fact also "rolling upgrades" (which fans of the concept keep forgetting to mention) - is one of the reasons, IMHO.

Note the SLE also upgrades packages. The ~1000 package updates in SP2 weren't minor at all.

Do they also remove packages? Like it's currently discussed about ruby 2.1 and 2.3 or kde4? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/24/2017 02:00 PM, Richard Brown wrote:

On 24 March 2017 at 13:59, Rüdiger Meier wrote:

...

On 03/24/2017 01:25 PM, Ludwig Nussel wrote:

...

...

Note the SLE also upgrades packages. The ~1000 package updates in SP2 weren't minor at all.

Do they also remove packages? Like it's currently discussed about ruby 2.1 and 2.3 or kde4?

Yes

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/#Packages.Deprecat...

Though this list looks very short, well documented and hits only very specialized modules. I don't see that they would remove whole scripting languages (PATHs which users may use as shebang) or whole desktop-suites. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/24/2017 04:23 PM, Richard Brown wrote:

On 24 March 2017 at 14:31, Rüdiger Meier wrote:

...

On 03/24/2017 02:00 PM, Richard Brown wrote:

...

On 24 March 2017 at 13:59, Rüdiger Meier wrote:

...

On 03/24/2017 01:25 PM, Ludwig Nussel wrote:

...

...

...

Note the SLE also upgrades packages. The ~1000 package updates in SP2 weren't minor at all.

Do they also remove packages? Like it's currently discussed about ruby 2.1 and 2.3 or kde4?

Yes

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12-SP2/#Packages.Deprecat...

Though this list looks very short, well documented and hits only very specialized modules. I don't see that they would remove whole scripting languages (PATHs which users may use as shebang) or whole desktop-suites.

SLES doesn't have desktop suites to remove. They only have GNOME. There is no KDE4 to remove. There is no KDE5. There is no xfce, enlightenment, lxde. There is only GNOME

Isn't Gnome example enough? If SLE would not remove Gnome so Leap should not remove KDE.

SLES doesn't have whole scripting languages to remove

No? What about python3? Leap 42.2 is still missing the 3.4.6 minor upgrade from SLE, probably because we did not follow SLE in 42.1. And now for 42.3 it's just luck that it was not even upgraded to 3.5 already (just to support latest KDE or Blender).

SLE (SLES+SLED+more) is something like 2500 packages vs openSUSE Leap which is approaching 10000 packages

Being 4 times bigger means there's going to be at least 4 times the number of examples of hard decisions like deprecations or version upgrades in order to be able to deliver something that works as a coherent distribution.

I still don't get it. As a former Evergreen-11.4 and 13.1 user I could have all these 10000 packages for many years without being bothered by hard, incompatible decisions. Most of my systems are still on 13.1.

openSUSE Leap is a more complex distribution than SLE, to make things all work together we either have to make the hard decisions to not move things (which then has people complain its too old)

They can complain whatever they want. There are enough alternative distros providing the latest stuff. Actually I'm feeling now like having completely wrong understanding about Leap. Is it a stable LTS distro or not? Is it a replacement for Evergreen, or not?

or the hard decisions to move things (which then has people complain about changes, removals of packages, etc)

My impression is that these decisions are actually not hard. More like "Let's change it, I think it would be good. Don't want to maintain different packages for TW and Leap". texlive was already upgraded before 42.3 development was officially announced.

It's a fact of life, your understanding & support would be beneficial and would be appreciated.

Your contributions to help deal with any issues that affect you are appreciated even more.

Still trying to figure out whether Leap is the right choice for me at all. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/24/2017 06:02 PM, Luca Beltrame wrote:

Il giorno Fri, 24 Mar 2017 17:32:43 +0100 Rüdiger Meier ha scritto:

...

because we did not follow SLE in 42.1. And now for 42.3 it's just luck that it was not even upgraded to 3.5 already (just to support latest KDE or Blender).

For the record, I asked for a Python upgrade[1], I got turned down with very good reasons, so I cooperated with upstreams (KDevelop) to ensure their software (kdev-python) would work also with 3.4 (it required 3.5 due to deliberate breaking changes in 3.4.x).

Yes, this case went well as it should, thanks. However, speaking for me I would have filed the bug at KDE first. It would never come into my mind to upgrade a well maintained and heavily used global python installation, plus forcing all our users to reinstall all their local PYTHONUSERBASE and PYTHONPATH, plus reviewing all our production scripts for py-3.5 compatibility ... just to get a certain window-manager running. Moreover there is already KDE in 42.2 which obviously works with python 3.4.

...

Actually I'm feeling now like having completely wrong understanding about Leap. Is it a stable LTS distro or not? Is it a replacement for

One of the desktops (the default) is actually a LTS version, and will not get upgraded (save to the latest minor release).

...

like "Let's change it, I think it would be good. Don't want to maintain different packages for TW and Leap". texlive was already

You seem to underestimate the effort of tracking a lot of packages for desktops like GNOME or KDE's Plasma.

Besides, do you want to ship codebases that will not receive either bugfixes or security updates? Simple utilities *may* be fine, some more complex programs not.

Well, if certain upstream projects don't maintain their bugs in an way usable by LTS-distros, then we can either skip such projects or just provide them as they are including the bugs (this is BTW my understanding of the major difference between SLE and Leap). Most of our users are old enough to decide for themselves which software is promising and which one is not. Everybody has made his own experiences. For example after KDE3/4 drama I would never again waste my time with any of these bloated window managers like KDE, Gnome or XFCE [1] as I've learned they will behave differently every year or just disappear. Also they have too many dependencies ... As a developer I want to select my python or compiler independent of what is "supported" by my email program ... and moreover neither my installed python version nor my mindow-manager should not hinder me to upgrade my email program whenever I want. So simple is that. [1] XFCE might be a bit less bad example. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 March 2017, Ludwig Nussel wrote:

Rüdiger Meier schrieb:

...

[...] IMO we should finally start to revert things which break other things. For example the texlive update in 42.3 ... Please revert it! Lets make

I haven't seen any other opinions on this one.

IMO more important, I have also not seen any reason why texlive needs to be updated each Leap minor release. I repeat myself again. There is TW for this. In this case also all the (IMO mostly dishonest) concerns seen in this thread about to much work to maintain old versions, double work for TW and Leap, etc. do not count because we disconnected texlive from SLE-12 on purpose.

Rudi might be a bit more grumpy about this case as the texlive update caused a build failure in one of his packages (sbcl). Apart from that texlive looked like an easy update candidate to me.

For me the successful build of the whole Leap distro is some kind of minimal test-case which we should not break. I do not care much about my particular sbcl package. Just can't understand why it breaks each minor Leap update. How could it be worse on the old non-LTS release model? Users who need an LTS distro for example to use it as stable build host for their in-house continuous integration services should better not use Leap, as long as not even Leap itselves survives it's own build. Could you imagine how many trouble tickets more github/travis-ci would get if they would use Leap instead of Ubuntu LTS? I'm not grumpy just to be grumpy. I want to see an LTS openSUSE distro, stable, without surprises. So far there is no LTS since Evergreen is on hold. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-03-28 15:25, Fabian Wein wrote:

Rüdiger Meier wrote:

...

Users who need an LTS distro for example to use it as stable build host for their in-house continuous integration services should better not use Leap, as long as not even Leap itselves survives it's own build.

I see three different kinds of distros: * LTS, e.g. for servers * modern and fresh desktop system I have to upgrade from time to time * a rolling distro like TW where I need have to accept additional hassles.

I work in academia and we use Linux for scientific work. We develop in C++/Python use cmake/gnuplot/octave/... and use Linux based clusters.

I'm the only one using TW and it is annoying when our LTS servers become outdated (gcc/cmake/gnuplot). The colleagues regularly update their desktop distros (sometimes skipping a version).

My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time. And I personally see TW not as stable as a standard desktop distro.

So I do not understand your calling for making Leap strict LTS, or do I miss something?

Fabian (a user)

Making Leap a strict LTS would void a lot of its utility to many people, IMHO. - -- Cheers / Saludos, Carlos E. R., another user. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAljaaFMACgkQja8UbcUWM1zyKQD+J02bBtt6EjzwcEXTkbUnv0rM 4K2Qd9eQutQEEezDkKIA/0amCYkyeTytkMJKrYFSXPJ4C9a1Sspx0pTc2jNwtTsC =FIA4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Rüdiger Meier wrote:

The key here is that you and your colleagues update your machines whenever YOU want. If another guy (your admin) would do this with your machines a few times per year overnight then you would probably know what I'm talking about.

We are happy to have control on our desktops and servers by ourselves, simply as our group has no admin and the central adminstration is not flexible enough for our needs.

I'd say _especially_ in science where you sometimes have to reproduce results from old papers, etc. it has a lot value for users that they maintain their most heavily used software by themselves (gnu-modules/virtualenv/anaconda/whatever). Much better than using randomly whatever comes with your distro. But to make such local installations usable/possible you have to give them an LTS distro. Otherwise their local installation will break on every distro upgrade.

I have the impression you don't understand. For our desktops we *don't want* an LTS with most of the time outdated versions. This is different from servers and clusters but we sit 40h/week in front of our desktops.

So if you are unhappy with your current mixed LTS/TW/colleagues machines, I'm sure you all could have it a lot easier if you all would use the same LTS distro, plus modules/virtualenv as described.

You missed the desktops: We have desktop distros (just me with TW) and LTS on servers/clusters. Currently we are happy. But I feel you want to remove a modern desktop distro without replacement.

like "why this is working for you but not for me" should be more seldom. Just ask your cluster admin for help or providing such modules. The reason is currently that either they have to use non-standard repos or build manually to have the cmake/python/gdb/... stuff that works for me on TW or I have to fight my TW because I cannot run the commercial Intel vTunes performance analyzer due to kernel incompatibilities.

...

My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time.

Isn't TW up-to-date enough? It is, but in my eyes not necessarily robust enough for general broad

Once again, we *don't want* LTS desktop systems, simply for the reason that for our use cases it is good to have newest software. We prefer "newer" instead of "stable and old" for our desktops. productive desktop use. Fabian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28 March 2017 at 18:24, Daniele wrote:

Il 28/03/2017 17:23, Fabian Wein ha scritto: ....

...

Once again, we *don't want* LTS desktop systems, simply for the reason that for our use cases it is good to have newest software. We prefer "newer" instead of "stable and old" for our desktops.

IMHO, the old behavior (pre Leap) was a very good compromise. I miss it..

...

...

...

My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time.

Isn't TW up-to-date enough?

It is, but in my eyes not necessarily robust enough for general broad productive desktop use.

I agree with you here, almost every week there's something broken/half working or not well tested at least..

The hole between Leap and TW is too big. I'm very worried of what will happen with Leap 43, a big jump in software version will break a lots of things..

Daniele.

The old behaviour was a gap that was much larger than the gap between Leap and TW I find your points contradictory - if you preferred the old behaviour, how could you then worry about the much smaller gap than we now have compared to back then? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 28 March 2017 at 17:23, Fabian Wein wrote:

...

Rüdiger Meier wrote:

...

The key here is that you and your colleagues update your machines whenever YOU want. If another guy (your admin) would do this with your machines a few times per year overnight then you would probably know what I'm talking about.

We are happy to have control on our desktops and servers by ourselves, simply as our group has no admin and the central adminstration is not flexible enough for our needs.

...

I'd say _especially_ in science where you sometimes have to reproduce results from old papers, etc. it has a lot value for users that they maintain their most heavily used software by themselves (gnu-modules/virtualenv/anaconda/whatever). Much better than using randomly whatever comes with your distro. But to make such local installations usable/possible you have to give them an LTS distro. Otherwise their local installation will break on every distro upgrade.

I have the impression you don't understand. For our desktops we *don't want* an LTS with most of the time outdated versions. This is different from servers and clusters but we sit 40h/week in front of our desktops.

...

So if you are unhappy with your current mixed LTS/TW/colleagues machines, I'm sure you all could have it a lot easier if you all would use the same LTS distro, plus modules/virtualenv as described.

You missed the desktops: We have desktop distros (just me with TW) and LTS on servers/clusters. Currently we are happy. But I feel you want to remove a modern desktop distro without replacement.

...

like "why this is working for you but not for me" should be more seldom. Just ask your cluster admin for help or providing such modules.

The reason is currently that either they have to use non-standard repos or build manually to have the cmake/python/gdb/... stuff that works for me on TW or I have to fight my TW because I cannot run the commercial Intel vTunes performance analyzer due to kernel incompatibilities.

Once again, we *don't want* LTS desktop systems, simply for the reason that for our use cases it is good to have newest software. We prefer "newer" instead of "stable and old" for our desktops.

...

...

My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time.

Isn't TW up-to-date enough?

It is, but in my eyes not necessarily robust enough for general broad productive desktop use.

Fabian

I would like to take this point in the thread to conduct a 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 I am about to suggest should not be taken as an indication that SUSE are even considering the below. Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution? 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) - Release schedule that lags SLE (would only be able to release *AFTER* SLE, whereas Leap we can develop it WITH SLE because we're working together) 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. If the answer to the above is Yes the follow up questions are Would you like this in addition to Leap, or instead of? What use cases would you use it for which Leap couldn't do? Would this mean reducing the scope of Leap? Would you be willing to contribute to/release manage/help maintain/support such a distribution? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mike Galbraith composed on 2017-03-28 19:40 (UTC+0200):

On Tue, 2017-03-28 at 19:07 +0200, Richard Brown wrote:

...

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)

One DE.. Gnome or nothing? Scary thought. Indeed. :-(

Were that to ever become the only choice, I'd have to either find a new distro,... ++

...or go back to rolling my own (ton of work that, I'm too old/lazy to go there again;).

Never did that, and I'm too old to start trying. A reversion away from Linux might be easier, if its web browser limitation can be overcome: https://www.arcanoae.com/ -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/29/2017 05:47 AM, Ruediger Meier wrote:

On Tuesday 28 March 2017, Felix Miata wrote:

...

Mike Galbraith composed on 2017-03-28 19:40 (UTC+0200):

...

On Tue, 2017-03-28 at 19:07 +0200, Richard Brown wrote:

...

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)

One DE.. Gnome or nothing? Scary thought.

Indeed. :-(

Hehe I don't find any openSUSE Desktop useful since 11.4 and I'm still using openSUSE.

I was in the same boat but then I found a desktop I liked packaged it and started maintaining it and I am no longer in that boat :-) -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Tue, 28 Mar 2017 19:07:26 +0200 Richard Brown wrote:

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?

For me such a distribution would be useless. If it would replace Leap I would probably have to take the risk and use TW instead, which I would rather avoid. Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 29 Mar 2017 14:42:20 +0200 (CEST) Johannes Meixner wrote:

On Mar 28 20:08 dieter wrote (excerpt):

...

On Tue, 28 Mar 2017 19:07:26 +0200 Richard Brown wrote:

...

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?

For me such a distribution would be useless.

Why?

Currently I understand (perhaps misunderstand) your comment as if SLE would be useless but reality shows the opposite.

Maybe I should have tried to emphasize the *FOR ME* more. I tried to describe *my* use cases and preferences in this message: http://lists.opensuse.org/opensuse-factory/2017-03/msg00864.html Richard wrote "(ie. pretty much 1 tool for 1 task. One DE, One web server)" therefore I assume many of my favorite tools would not be included, and so this distribution would not be my choice. I am aware there are other scenarios in which an SLE type of distribution is better than Leap, or in other scenarios TW is the best. There are many different tastes and priorities and I do not believe there is a "one size fits all". BTW: please keep replies to the list. Kind regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Il 28/03/2017 19:07, Richard Brown ha scritto: ..

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution? Do you really want me to change distro after 20 (almost) years ??

Please not... Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 March 2017, Richard Brown wrote:

On 28 March 2017 at 17:23, Fabian Wein wrote:

...

...

Rüdiger Meier wrote:

The key here is that you and your colleagues update your machines whenever YOU want. If another guy (your admin) would do this with your machines a few times per year overnight then you would probably know what I'm talking about.

We are happy to have control on our desktops and servers by ourselves, simply as our group has no admin and the central adminstration is not flexible enough for our needs.

...

I'd say _especially_ in science where you sometimes have to reproduce results from old papers, etc. it has a lot value for users that they maintain their most heavily used software by themselves (gnu-modules/virtualenv/anaconda/whatever). Much better than using randomly whatever comes with your distro. But to make such local installations usable/possible you have to give them an LTS distro. Otherwise their local installation will break on every distro upgrade.

I have the impression you don't understand. For our desktops we *don't want* an LTS with most of the time outdated versions. This is different from servers and clusters but we sit 40h/week in front of our desktops.

...

So if you are unhappy with your current mixed LTS/TW/colleagues machines, I'm sure you all could have it a lot easier if you all would use the same LTS distro, plus modules/virtualenv as described.

You missed the desktops: We have desktop distros (just me with TW) and LTS on servers/clusters. Currently we are happy. But I feel you want to remove a modern desktop distro without replacement.

...

like "why this is working for you but not for me" should be more seldom. Just ask your cluster admin for help or providing such modules.

The reason is currently that either they have to use non-standard repos or build manually to have the cmake/python/gdb/... stuff that works for me on TW or I have to fight my TW because I cannot run the commercial Intel vTunes performance analyzer due to kernel incompatibilities.

Once again, we *don't want* LTS desktop systems, simply for the reason that for our use cases it is good to have newest software. We prefer "newer" instead of "stable and old" for our desktops.

...

...

My understanding is that having only TW and LTS Leap would mean that there is no modern desktop available most of the time.

Isn't TW up-to-date enough?

It is, but in my eyes not necessarily robust enough for general broad productive desktop use.

Fabian

I would like to take this point in the thread to conduct a 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 I am about to suggest should not be taken as an indication that SUSE are even considering the below.

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?

Yes. Though I would say just all _common_ packages should be the same. (Maybe a few exceptions for branding stuff or other things I don't know about yet.)

The main difference from Leap would be - absolutely no divergence from SLE, period - no additional community packages in the distribution

This "no additional" point is something I don't like as strict, but see below.

(ie. pretty much 1 tool for 1 task. One DE, One web server)

Isn't IceWM also in SLE?

- Release schedule that lags SLE (would only be able to release *AFTER* SLE, whereas Leap we can develop it WITH SLE because we're working together)

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.

If the answer to the above is Yes the follow up questions are

Would you like this in addition to Leap, or instead of?

Leap (or whatever name) could just like an addon repo containing all the missing 7500 packages which are not in SLE. It should be still carefully maintained, fixed versions at the first release, updates only for very good reasons. Moreover if we could agree about 100% SLE base. Then it could be even easy to provide more than one such addon repo, like Leap-very-stable, Leap-fairly-stable. In other words "very-stable" would still look more like 42.1 while "fairly-stable" goes direction 42.3. These addon repos could be even valuable for regular SLE subscribers as I guess the actual SLE backport repos have only a small community and do not provide as many packages as Leap.) Note I do not think that all SLE packages are always better than Leap. I just think that the SLE package selection is big enough and fixed enough to cool down the Leap updaters for more stability if we restrict ourselves to not break that base.

What use cases would you use it for which Leap couldn't do?

I want a distro where self-built binaries don't break because of maintanance upgrades. This point is my most important point speaking as sysadmin. I don't want that my (mostly very advanced) users hate me. Also I want "source-compatibility", I mean that a software which builds fine on 42.1 should still build on 42.3. The best test for this is the OBS repo aleady. It should not be allowed that one packager breaks the package of another packager. Think about developers using Leap as CI build host.

Would this mean reducing the scope of Leap?

IMHO this would be exactly what I thought Leap is supposed to be. Moreover I would say this would make the scope bigger. Regarding the unhappy people who want more the newest stuff. IMO we should keep an eye of making more packages able to be installed in several versions in parallel, so that pulling from 3rd party repos is less painful.

Would you be willing to contribute to/release manage/help maintain/support such a distribution?

Yes, of course. On the other hand I will not provide any build fix anymore for current Leap, for example my sbcl package. This is waste of time IMHO. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 March 2017, Stefan Seyfried wrote:

Am 28.03.2017 um 20:58 schrieb Ruediger Meier:

...

I want a distro where self-built binaries don't break because of maintanance upgrades.

Do you have an example of such breakage on Leap?

I was not only speaking about _binaries_ but also about scripts using a versioned shebang or relying on a certain default interpreter. regarding https://build.opensuse.org/request/show/477529 https://build.opensuse.org/request/show/477530 Or regarding the idea to update python 3.4 to 3.5 just to get a KDE upgrade running. I dont find that bug report again right now. It was was luckily declined but would have made all locally installed python3 packages unusable.

I'm running self-compiled binaries that I compiled 10 years ago on Leap and even tumbleweed without problems.

Of course for real binaries we have some kind of lsb standard interface which seems to work quite good (at least for libc deps). Moreover experienced non-admin-users would compile static anyways. Nethertheless I'm 100% sure that I would find incompatible libtool/.so versions for whatever lib on TW since 10 years. And I'm almost sure that I would also find one between Leap releases. Maybe just my prejudices but it's not hard to imagine that someone builds a kde4 app against global libs and that it would not work anymore if kde4 is removed. cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 28 March 2017, Wolfgang Bauer wrote:

Am Dienstag, 28. März 2017, 22:27:36 schrieb Ruediger Meier:

...

Maybe just my prejudices but it's not hard to imagine that someone builds a kde4 app against global libs and that it would not work anymore if kde4 is removed.

Hm, after reading all these mails, I still don't understand where you got this paranoia from.

I have not any paranoia, KDE is usually just a nice example regarding annoying incompatibilities.

First, there is no such thing as a "kde4". Second, nobody suggested to remove "kde4" anyway.

The only thing that was mentioned was "kdepim", which is a suite of "Personal Information Management" software, similar to evolution.

We are going to drop the old, unmaintained 4.x version. And kdepim is still shipped anyway, the latest version at this time.

The "KDE4" kdelibs will stay. So you will also still be able to build applications that use it.

The "KDE4 desktop " (Plasma1) was dropped already in Leap 42.1, the last openSUSE release that used and supported it was 13.2. So no regression there...

Good to know, Though the discussion about removing kdepim4, etc. was about not maintaining EOL stuff. So I wonder now why you still provide kde4 libs. Are they still maintained by upstream? cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/29/2017 05:28 AM, Ruediger Meier wrote:

On Tuesday 28 March 2017, Richard Brown wrote:

...

On 28 March 2017 at 17:23, Fabian Wein wrote:

...

...

Rüdiger Meier wrote:

I would like to take this point in the thread to conduct a 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 I am about to suggest should not be taken as an indication that SUSE are even considering the below.

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?

Yes. Though I would say just all _common_ packages should be the same. (Maybe a few exceptions for branding stuff or other things I don't know about yet.)

...

The main difference from Leap would be - absolutely no divergence from SLE, period - no additional community packages in the distribution

This "no additional" point is something I don't like as strict, but see below.

...

(ie. pretty much 1 tool for 1 task. One DE, One web server)

Isn't IceWM also in SLE?

It is but most would argue it is still just a window manager not a full desktop.

...

- Release schedule that lags SLE (would only be able to release *AFTER* SLE, whereas Leap we can develop it WITH SLE because we're working together)

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.

If the answer to the above is Yes the follow up questions are

Would you like this in addition to Leap, or instead of?

Leap (or whatever name) could just like an addon repo containing all the missing 7500 packages which are not in SLE. It should be still carefully maintained, fixed versions at the first release, updates only for very good reasons.

Richard didn't suggest this and probably for several very good reasons here are some. Firstly there will be libraries as an example with different versions between SLE and Leap, often we are quite happy to have only 1 version of these libraries so know one has bothered to setup multi version support. Say we have library A that has version 1.0.1 in SLE and 1.0.2 in Leap, Now package X that is only in leap will be built against the newer version of A and as such may use symbols only found in the 1.0.2 version, running X on the SLE based system will cause it to crash at startup unless its rebuilt, and supposing we chose to rebuild it in this special new repo should the build fail because X requires the 1.0.2 version of A who is going to fix it? are you asking all the maintainers to now start supporting another distro? I could go onto the fact that this extra repo wouldn't be tested so would probably contain bugs which would harm our reputation unless people also step up for testing. I'm sure some others would come up with other reasons why this wouldn't work and why it would have to be just SLE with different branding / wallpaper packages. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Would the users and contributors on this list be interested in a 100% matching SLE-like LTS distribution?

I am personally not. With two exceptions (me with TW and one Ubunutu) we have Leap as desktops and Ubuntu LTS on our two servers. Doing a lot of software development (but not Linux administration) I regularly enjoy the much more developer focus of openSUSE (better defaults in bash, history in gnuplot, and a lot of things I enjoy daily but being no professional administrator I don’t know how to enable in Ubuntu). But even with a Leap LTS we wouldn’t change the distro for our servers. The HPC clusters we use were running on SLE 11, without loading newer stuff by modules we were not able to compile our software (we use C++11 features). They recently switched to Ubuntu LTS which I regret, I would have preferred a newer SLE but I’m just a user, I wasn’t asked.

Would you be willing to contribute to/release manage/help maintain/support such a distribution?

Independent on the question behind, I as a user won’t be able to actively contribute to openSUSE. I feel uncomfortable with this selfish approach but it is the way it is and I very much appreciate the effort and support of all of you! Thanks a lot!! Fabian-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/31/2017 06:24 AM, Christian Boltz wrote:

Hello,

Am Dienstag, 28. März 2017, 19:07:26 CEST schrieb Richard Brown:

...

I would like to take this point in the thread to conduct a 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 I 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 board member".

...

- Release schedule that lags SLE (would only be able to release *AFTER* SLE, whereas Leap we can develop it WITH SLE because we're working together)

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 version.)

With very rare exception SLE's longer lifetime fixes[1] go into a LTSS repository, only certain customers who pay for additional LTSS support these packages aren't currently in openSUSE's obs (from what I can tell) and I doubt that these would be added given the potential loss of a significant revenue stream. 1. https://www.suse.com/lifecycle/ -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Tue, 28 Mar 2017 09:49:40 +0200 Ludwig Nussel wrote:

I haven't seen any other opinions on this one. Rudi might be a bit more grumpy about this case as the texlive update caused a build failure in one of his packages (sbcl). Apart from that texlive looked like an easy update candidate to me.

As you asked for opinions: I use Leap as a Desktop operating system. I need a system which is working reasonably stable so it does not keep me from doing my actual work. On the other hand I need a system which has reasonably recent software packages so e.g. interoperability with users of other systems is mostly working. What I expect from a "distribution" is to offer most of the tools I need recent and stable enough to do my work. I am not interested to install package A from home-repo X and package B from home-repo Y ... to build a system myself which does what I need. I am glad the contributors to Leap do this for me - thanks! That said I am quite satisfied with Leap as it is now. Originally I was very sceptic about the approach to combine the typically "aged" versions of an enterprise distribution with recent desktops and desktop software, but for me it works. It is probably comparatively easy to provide "the newest software" (like TW does), but almost impossible to provide absolutely stable software for all use cases. Regards, Dieter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org