On Tue, Apr 28, 2015 at 2:41 PM, Cristian Rodríguez wrote:

On Tue, Apr 28, 2015 at 11:09 AM, Christoph Grüninger wrote:

...

Dear openSuse,

is there a road-map for the next openSuse release 13.3? I could not find one at the usual location https://en.opensuse.org/openSUSE:Roadmap

According to the 8 months plan and the last release in November, I could expect early June for the next release. Obviously, this is not the plan. What's the plan instead? If you make changes, please tell us users.

Unless I am missing something, the release schedule has not been discussed yet on this list.

No definitive answer, but definitely discussion: http://markmail.org/thread/cnzilu3erwkjekvi There was even a community poll with 1278 votes currently shown. https://plus.google.com/+openSUSE/posts/g5FdGJ9iSqB Most popular by far was a 1 year release schedule. Coolo said he'd rather not do a release at all and just use Tumbleweed. http://markmail.org/message/iiheijcgclfvb2cy I'd say at this point the answer is "openSUSE 13.3 will not be released before Nov 2015". Greg -- 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: SHA1 On 04/28/2015 08:14 PM, Carlos E. R. wrote:

On 2015-04-28 21:59, Greg Freemyer wrote:

...

On Tue, Apr 28, 2015 at 2:41 PM, Cristian Rodríguez

...

Coolo said he'd rather not do a release at all and just use Tumbleweed.

TW is not suitable for everybody :-(

Heh, very true. I have tried it, really great actually but I think I prefer 13.2 as my stable environment :) - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQCwQAAoJEM66EOTZRH6+y8MQALVQAHxZ5NNNIAeTMtCpqQgT 3ozALeK7lq1+mAP121hzvBl5QvuLE8ctJgJJDqphjJIW9VqqmXjOtqm6nWSvo74e v4aDLI21bzWOpb/821IiseRMBivNNpEFzk+57Oz47imFSgt6rPmCGWP/Vfa26mFA sXiGdSGqd5ipn9/gksWA01DJW7AfMSpGYwNizitBNDzangm2TDldKiHNAJXMmfoS oSG0QKQ8OVHjhiE6R5AIjFORMqAG83ORY7XnEkoEVCsNZY+6SwHMlMnECnxg4eFR YVr0TZYPnvQFMl7oEtNX4COps8tPUu5q8SD3UVWUWFnnzOJDXE2Wu30MCQlco8qd 9cuMKZLa/iqxZWuGpk8rIQeEk80bYKJfCm5MOyKosF5NlKRIaOvNZgt3XFrxZBAb YkQObBtLbBTlwdgwv64vCYKgAZMiN4X4yRciUSMxnAS9VLSfOsXlzjVzuIXY9BjC MpP0uZg/KzZjeGcGYItJ2mKZz0aTniGbJpz0nHQl6qKPZM/IAFtNWa6R+O73JpCY JQY+gK2829Dbza+c/+EBTGSEXH125XPY8ewZAApL3aIHZU0l0ROv2me/mnqqVlpK GE/9jPig04uW87VXdTLrfEn8JOMPJHLFL5I0kswaXkSJsiapwKJzzYsgAn1lz8u5 J4w68GsRhmJO0u+8dMB0 =Gvrj -----END PGP SIGNATURE----- -- 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: SHA1 On 29.04.2015 02:14, Carlos E. R. wrote:

On 2015-04-28 21:59, Greg Freemyer wrote:

...

On Tue, Apr 28, 2015 at 2:41 PM, Cristian Rodríguez

...

Coolo said he'd rather not do a release at all and just use Tumbleweed.

TW is not suitable for everybody :-(

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

13.2 obviously isn't either - so what's your point? Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVAiqkACgkQwFSBhlBjoJaXfwCdEpFgyV7+kP2RQ6zB6nDw4yTJ mN4An1izhczFQCdTypQQnVzh6LWVhxeT =n4OY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi All, I've just made an announcement on the opensuse-project mailinglist which may influence this discussion somewhat http://lists.opensuse.org/opensuse-project/2015-04/msg00104.html After my presentation on Friday, where I'll be able to go into more details of what SUSE are doing and how we may (or may not, this is all proposals at this point) wish to adopt that inside openSUSE, I think it might make more sense to revisit this topic then with that new information. Hope this helps, Richard On 29 April 2015 at 10:55, Christoph Grüninger wrote:

Hi!

...

...

TW is not suitable for everybody :-(

13.2 obviously isn't either - so what's your point?

The point is to have both. A release every 12 months would be ok. But not having a stable release at all, would be a bumper for me.

Anyhow, I would expect to share such thoughts to the wider audience. I was not aware of the current spirit against stable releases. Whenever you want to change openSuse to a rolling release, please announce it or start an according discussion. But letting creepingly die the releases, is kind of betraying the users.

What does the openSuse Board thinks about the recent development? Can they either rule or moderate a discussion what openSuse should aim for?

Best Christoph -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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

On 29 April 2015 at 13:52, Stanislav Baiduzhyi wrote:

Hi Richard,

Please make a recording of that presentation and put it online somewhere, for people who will not be able to attend.

-- Regards, Stas

We will :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 29 of April 2015 09:39:25 Stephan Kulow wrote:

On 29.04.2015 02:14, Carlos E. R. wrote:

...

TW is not suitable for everybody :-(

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

13.2 obviously isn't either - so what's your point?

I don't quite understand yours. To me, it makes pretty good sense that someone who doesn't upgrade to every distribution release and decides to skip one is even less likely to be happy with rolling upgrades. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, 29 Apr 2015 11:12, Stephan Kulow wrote:

On 29.04.2015 10:58, Michal Kubecek wrote:

...

On Wednesday 29 of April 2015 09:39:25 Stephan Kulow wrote:

...

On 29.04.2015 02:14, Carlos E. R. wrote:

...

TW is not suitable for everybody :-(

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith))

13.2 obviously isn't either - so what's your point?

I don't quite understand yours. To me, it makes pretty good sense that someone who doesn't upgrade to every distribution release and decides to skip one is even less likely to be happy with rolling upgrades.

I'm not saying anything else - I just don't like Carlos' one sentense replies. Expressing his problems with Tumbleweed (or better the possible lack of 13.3) is one thing, but throwing statements onto mailing lists doesn't help anyone.

Greetings, Stephan

What is the situation? for a fixed release (version number as you like), the past has shown that six month is what it takes at minimum to get a (mostly) stable set of packages that can be called "release" without being ashamed afterwards. We've had the "great" releases, (10.2, 11.4, and even 12.3) and the "not-so-great" releases (the last was 13.2), what was the difference? For 13.2 it was the whole network-config issue that took down the overall impression. Wicked was just NOT ready yet, and this was felt like a supersonic-knell through the whole system. Every network-depended service hat its own issues with that, some could cope, some through up. For me a openSUSE release is not about a "killer-feature", but about a complete system done right. If I really want just a specific "killer-feature", I take a distro that features just that. DistroWatch and Linux magazines are great for that. The real question is: Is TW in a shape that with 6 month work it can be worthy of the title "release", or do we get another set of last-minute untested software get pressed on? Keypoints for me: * Btrfs on / is not in a shape that acceptable for the masses. - fillup: either the snapper defaults get corrected, or other config screws get turned in the right directions. - stability: Ready to run for the next 3-4 Years after install? Sadly not at the moment. - Missing repair tools, and step-by-step manuals for crashes. * Snapper docu is still not complete in the packages, config missing. * Network: - where IS the full wicked docu? Not in the packages! - up-to-date HowTo's for the different scenarios: + prefer cable, but use wifi if no cable, + vlan, + ipsec, + ipv6 (state of the art, please), + dnssec, authenificating forwarders, + firewall and virtual-machines (hello, docker!) To me it looks like that we really have to get started if we want a "release" in November. - Yamaban. -- 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 2015-04-29 10:58, Michal Kubecek wrote:

On Wednesday 29 of April 2015 09:39:25 Stephan Kulow wrote:

...

On 29.04.2015 02:14, Carlos E. R. wrote:

...

TW is not suitable for everybody :-(

...

13.2 obviously isn't either - so what's your point?

I don't quite understand yours. To me, it makes pretty good sense that someone who doesn't upgrade to every distribution release and decides to skip one is even less likely to be happy with rolling upgrades.

Absolutely. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVA5/IACgkQja8UbcUWM1zuywEAkI04QCwOdL/9I85o5BcXrxTK pQj232NfIMABRtAvpn8A/jmOD43bwDQhsLNEjTHu5kAqF3h8/3GMIlyNC3/ApnTL =cIPd -----END PGP SIGNATURE----- -- 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 2015-04-29 16:22, James Mason wrote:

On 04/29/2015 07:17 AM, Carlos E. R. wrote:

...

...

...

I don't quite understand yours. To me, it makes pretty good sense that someone who doesn't upgrade to every distribution release and decides to skip one is even less likely to be happy with rolling upgrades. Absolutely.

That person should be using an Evergreen release, at this time.

Not necessarily. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVA6doACgkQja8UbcUWM1yiJAD+KqsO9eEI5EIP9v8Y7LRles5a gZb7JN+6X88ZQJBISkwA/R4Ybgkd6iRd9ZTTW6UCvYxpIESVgoW+dCksXnBv3NxB =MLFC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 29 April 2015 09:39:25 Stephan Kulow wrote:

On 29.04.2015 02:14, Carlos E. R. wrote:

...

On 2015-04-28 21:59, Greg Freemyer wrote:

...

On Tue, Apr 28, 2015 at 2:41 PM, Cristian Rodríguez

Coolo said he'd rather not do a release at all and just use Tumbleweed.

TW is not suitable for everybody :-(

13.2 obviously isn't either - so what's your point?

Why not? 13.2 has been great for me so far. As end user, who requires stable desktop, openSUSE with 6-8-12 month cycle gives the best possible solution ever. Rolling distros, like Tumbleweed or Fedora, are extremely inconvenient unless you are a developer *of* that distro. And on the other side, CentOS/RHEL is just too outdated, I do want to have latest Qt5+QtCreator, newer git/mercurial/giflib, and so on. openSUSE has this very attractive niche, being "stable but not ancient", and there is no competition in this niche as far as I know. Taking the best from both worlds, I would suggest the following: 1. Create repos for every part of the system separately. Already done (other distros can only envy). 2. Create 2 versions of those repos, stable and tumbleweed. Snapshotting from tumbleweed into stable once in a while, stabilizing that version. That is also done for most repos. That, in my opinion, gives amazing opportunity for developers to work on their piece of the system without encountering issues from other pieces. For example the development of phonon may become crazy hard if every two days gstreamer or alsa or pulseaudio gets broken or changes behaviour. 3. Create the installation media that will be configured to use 128 smaller repos instead of 2 "have-it-all" repos. That will allow changing only specific parts of the system to the tumbleweed by replacing "13.3" in the repo path to "tumbleweed". Speaking very egoistically, for me that would be the best possible option, as I will just replace the KF5 and Qt5 repos from stable to tumbleweed and have latest shiniest plasma, while not having to fix periodical kernel/systemd/Xorg/etc issues that may creep into their tumbleweeds. Of course that was very rough idea and some additional steps may be required, like some "stabilizing" repos where tumbleweed snapshots will live for some time before going to stable. I don't know all the nuances of the distro development, but I really hope that those options will be more convenient for both opensuse developers and target audience. -- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 29 April 2015 19.51:05 Martin Schlander wrote:

Onsdag den 29. april 2015 02:14:06 skrev Carlos E. R.:

...

On 2015-04-28 21:59, Greg Freemyer wrote:

...

On Tue, Apr 28, 2015 at 2:41 PM, Cristian Rodríguez

Coolo said he'd rather not do a release at all and just use Tumbleweed.

TW is not suitable for everybody :-(

But the co-existence of stable releases and TW, will/would mean that openSUSE as a whole would be for everybody, just about.

Hi Martin, No no no everybody that's a forbidden target, don't say for everybody, it's bad they told me :-) Still I share this vision. Still the unanswered question, by who? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Apr 29, 2015 at 02:54:30PM -0300, Cristian Rodríguez wrote:

Neither is every single software product out there.. ;-) Please make your case on what's the exact problem with having only rolling releases.

For me, the main reason is the fact that upgrades necessarily cause various kinds of problems from time to time. It's not only bugs and regressions but also intentional changes in program behaviour, config file syntax or semantics etc. It's acceptable for me to do a distribution upgrade once a year or two (less often on a server) when I reserve enough time to resolve these issues and I expect things to be broken temporarily. Having such issues continuously hitting me at random times in a "rolling upgrades" model is not acceptable for me. That's why I'm not using Tumbleweed on any of my machines and I do not intend to. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

...

On Wed, Apr 29, 2015 at 02:54:30PM -0300, Cristian Rodríguez wrote:

...

Neither is every single software product out there.. ;-) Please make your case on what's the exact problem with having only rolling releases. For me, the main reason is the fact that upgrades necessarily cause various kinds of problems from time to time. It's not only bugs and regressions but also intentional changes in program behaviour, config file syntax or semantics etc. It's acceptable for me to do a distribution upgrade once a year or two (less often on a server) when I reserve enough time to resolve these issues and I expect things to be broken temporarily. Having such issues continuously hitting me at random times in a "rolling upgrades" model is not acceptable for me.

That's why I'm not using Tumbleweed on any of my machines and I do not intend to. Yep, that is the issue with a rolling release. +1

I think so, too. Another solution might be to mark the affected packageswith this kind of changes. And each packet has to be assessed whether a jump to the next version without consequence for the function. Can several versions are skipped? And zypper has to handle this. This is a nice feature but a dream only. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Marcus Meissner wrote:

On Thu, Apr 30, 2015 at 10:18:14AM +0200, Torsten Gruner wrote:

...

...

Michal Kubecek wrote:

...

On Wed, Apr 29, 2015 at 02:54:30PM -0300, Cristian Rodríguez wrote:

...

Neither is every single software product out there.. ;-) Please make your case on what's the exact problem with having only rolling releases. For me, the main reason is the fact that upgrades necessarily cause various kinds of problems from time to time. It's not only bugs and regressions but also intentional changes in program behaviour, config file syntax or semantics etc. It's acceptable for me to do a distribution upgrade once a year or two (less often on a server) when I reserve enough time to resolve these issues and I expect things to be broken temporarily. Having such issues continuously hitting me at random times in a "rolling upgrades" model is not acceptable for me.

That's why I'm not using Tumbleweed on any of my machines and I do not intend to. Yep, that is the issue with a rolling release. +1

I think so, too.

Another solution might be to mark the affected packageswith this kind of changes. And each packet has to be assessed whether a jump to the next version without consequence for the function. Can several versions are skipped? And zypper has to handle this. This is a nice feature but a dream only.

What do you mean with affected packages?

We try to push out only "stable" and working tumbleweed snapshots and that seems to be working quite well already.

My Laptop is running Tumbleweed and I have so far not have had a single troublesome status.

Unless you have a really unusual laptop it is probably not very representative of the majority of use cases :-) At some point last year I had an issue with icmp redirects not working after an upgrade, it took three months to fix. -- Per Jessen, Zürich (12.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 30.04.2015 um 11:27 schrieb Michal Kubecek:

...

What do you mean with affected packages?

We try to push out only "stable" and working tumbleweed snapshots and that seems to be working quite well already.

My Laptop is running Tumbleweed and I have so far not have had a single troublesome status. The risk of regression is much higher on version upgrades than on usual updates. And as I wrote before, there are also intentional incompatibilities where the new version behaves differently, has some functions dropped, requires different config file syntax or interprets certain config values differently. That's why I consider the "rolling" word misleading: it suggests a mental image of a continuous process; but

On Thursday 30 of April 2015 10:30:23 Marcus Meissner wrote: there are changes that can't be "rolled" continuously over and will always be discontinuous.

With the traditional periodic releases, these things happen on distribution upgrades and I expect them to happen then. With Tumbleweed, I would have to expect they might potentially happen any time I run "zypper update".

What Torsten suggests would be marking such risky upgrades (what is risky does vary by package, of course) and allowing users to postpone them until they are ready to take the risk and handle the potential fallout.

Michal Kubeček

Yes, those are exactly my thoughtsyou wrote. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 30 Apr 2015 10:30:23 +0200 Marcus Meissner wrote:

What do you mean with affected packages?

We try to push out only "stable" and working tumbleweed snapshots and that seems to be working quite well already.

My Laptop is running Tumbleweed and I have so far not have had a single troublesome status.

So the current touch-pad configuration problem hasn't affected your laptop? Lucky. -- Graham Davis [Retired Fortran programmer - now a mere computer user] openSUSE Tumbleweed (64-bit); KDE 4.14.6; Kernel: 3.19.4; Processor: AMD Phenom II X2 550; Video: nVidia GeForce 210 (using nouveau driver); Sound: ATI SBx00 Azalia (Intel HDA) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 01.05.2015 um 00:48 schrieb Wolfgang Rosenauer:

Since I'm afraid of putting TW on a production machine I decided to try it in VirtualBox for quite some time (I reported issues earlier) and I can only say that still every other TW update will leave my VirtualBox TW installation unusable. Usually no X coming up anymore.

I wonder how much of that is related to Virtualbox though. I already added virtualbox to the staging projects so we make sure it always builds, but we don't test it at all. As my google mojo fails me to find a way to run VB inside qemu VMs, an option is to revive the VB backend of openQA - or run VB tests on IMPI servers. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/01/2015 07:31 AM, Wolfgang Rosenauer wrote:

Am 01.05.2015 um 13:14 schrieb Stephan Kulow:

...

Am 01.05.2015 um 00:48 schrieb Wolfgang Rosenauer:

...

Since I'm afraid of putting TW on a production machine I decided to try it in VirtualBox for quite some time (I reported issues earlier) and I can only say that still every other TW update will leave my VirtualBox TW installation unusable. Usually no X coming up anymore.

I wonder how much of that is related to Virtualbox though. I already added virtualbox to the staging projects so we make sure it always builds, but we don't test it at all.

As my google mojo fails me to find a way to run VB inside qemu VMs, an option is to revive the VB backend of openQA - or run VB tests on IMPI servers.

Xorg is immediately dying with a segfault with current TW version using vboxvideo for me. And yes, it might very well be an issue in the VBox version but the end result is: unusable (unfortunately)

Wolfgang

I have installed Tumbleweed on VmWare and X works. VirtualBox will be releasing V5.0 Beta 3 in a few days. I'm downloading Beta 2 to see if X works. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Roman Bysh [01-01-70 12:34]:

On 05/01/2015 03:10 PM, Roman Bysh wrote:

...

I have installed Tumbleweed on VmWare and X works. VirtualBox will be releasing V5.0 Beta 3 in a few days.

I'm downloading Beta 2 to see if X works.

Cheers!

Roman

Follow Up

Just tried Tumbleweed snapshot 20150430 and the problem still exists with X. Yast ncurses starts up. No gui.

Just so you know it does work for some of us: Tumbleweed 20150430 NVIDIA-Linux-x86_64-349.12 GeForce GTS 450 http://wahoo.no-ip.org/~pat/TWsnapshot1.jpg for the record, I have been running tw since Greg KH started it and have always been able to run yas2 (gui) althought I have had short periods of inability to use the nvidia prop drivers which usually were quickly solved with the help of Larry Finger, thanks for the support. I have also but not currently using vb, been able to run versions of openSUSE and other distros in a vb but only for experience, not productive use (my choice). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/01/2015 06:37 PM, Wilhelm Boltz wrote:

Am Freitag, 1. Mai 2015, 13:31:07 schrieb Wolfgang Rosenauer:

...

Am 01.05.2015 um 13:14 schrieb Stephan Kulow:

...

Am 01.05.2015 um 00:48 schrieb Wolfgang Rosenauer:

...

Since I'm afraid of putting TW on a production machine I decided to try it in VirtualBox for quite some time (I reported issues earlier) and I can only say that still every other TW update will leave my VirtualBox TW installation unusable. Usually no X coming up anymore.

I wonder how much of that is related to Virtualbox though. I already added virtualbox to the staging projects so we make sure it always builds, but we don't test it at all.

As my google mojo fails me to find a way to run VB inside qemu VMs, an option is to revive the VB backend of openQA - or run VB tests on IMPI servers.

Xorg is immediately dying with a segfault with current TW version using vboxvideo for me. And yes, it might very well be an issue in the VBox version but the end result is: unusable (unfortunately)

I'm running tumbleweed on virtualbox for the same reason for a while. X runs quite accurate here.

Greetings Willi

Perhaps you misunderstood. In VB, during the initial installation the Yast installer does not stay with the familiar gui. It switches to Yast ncurses. It looks like X server segfaults as Yast is about to start. I can see the Yast notifying me that it is starting up. Under normal circumstances I should be seeing the regular gui as in VmWare. Once the installation finishes and restarts X is working. My card is a GeForce 8600 GTS. When installing on a real partition everything is normal just like in openSUSE 13.2. I remember when the earlier isos were released. You know the ones that used to have the factory repos. Some time between March and April, X started behaving strangely during the initial set up, selection of packages and Grub2 of Tumbleweed in VirtualBox. I believe they are already looking into this. In the meantime, I'll stick with installing Tumbleweed on to real hardware. Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, Am 01.05.2015 um 16:51 schrieb Robert Schweikert:

On 04/30/2015 06:48 PM, Wolfgang Rosenauer wrote:

...

Since I'm afraid of putting TW on a production machine I decided to try it in VirtualBox for quite some time (I reported issues earlier) and I can only say that still every other TW update will leave my VirtualBox TW installation unusable. Usually no X coming up anymore. My confidence in TW as a working horse is really quite low while I had actually some hopes in it.

Well, but TW is not really intended to run on a "production" server. TW is targeted at developers that want the latest of X and do not mind getting the latest of Y in the process.

I wasn't talking about servers but TW as my every day desktop. It could very well be that my desktop wouldn't be affected since I would run natively there but there is not even a chance to check that out if it does not run under my preferred virtualization.

On a personal note I run TW on my laptop as it gets frequently rebooted anyway, but do not rnu TW on my desktop as I hate rebboting that machine. Simply it takes me 1/2 hour to get all my workspaces and terminals and and and back to the state before the reboot.

So now this is an unexpected statement since many many openSUSE community members claim that all you need is TW and nothing else and this was also what this part of the thread was about. Good to hear that this is apparently just an opinion of some very vocal part of the community. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 03 May 2015 14:23:03 Stephan Kulow wrote:

[...] All I'm saying is that the general contributor is a lot less interested in contributing into a stable release. 13.2 beta had very few testers, that's just no base to continue with the way we did openSUSE releases.

I am not sure this has changed to a better with the new TW. I never did run Factory, I did test some of the betas when I was still a student and had time, but until recently I just used 13.2 with addon repos (XOrg, KDE, ...). With the new TW, this has changed. One of my computers is running it (maybe more in the future), but for me it would be fine to switch it to some Tumbleweed-on-Ice for a month or two and help stabilize it. I need something I can be sure it works for the other computers, and although TW is quite good (or I am lucky) is not there yet, and I doubt it ever will be. TW has it made possible to run a testing version of openSUSE regularly - that is, every day. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 5 May 2015 at 21:40, Martin Schlander wrote:

It was also the first release based on the "new" factory/tumbleweed, with a very short testing phase (two devel releases with 2-3 weeks between) and iirc the roadmap itself was published very late.

Secondly, openSUSE releases shouldn't need as many testers/much testing as before, with Tumbleweed already being fairly well tested by a decent number of people running it full-time. At least I thought that was the idea.

The whole process of Tumbleweed based stable releases just needs a few small adjustments, to work well imo. (A roadmap, a slightly longer window to test things, a fixed 12 month release cycle, 26 months of lifetime (2 releases+2 months) would be a very good start).

From an Engineering perspective it was 'just' a Tumbleweed snapshot, but from a Marketing, Branding, 'actually getting a release out of the door' perspective, it required as much work as any other software release. For 13.2 this fell on the shoulders of a tiny handful of people. The reality is that Tumbleweed has captured the excitement of a huge

I understand where you're coming from, but I think there are a few things I'd like you to consider The 13.2 release required a large amount of work from a small number of people to make it a success. portion of our current contributing community, and grown it greatly, and that's great, but it does have the side effect of leaving less enthusiasm and less people to work on the Regular Release. As was discussed at the Project Meeting at oSC 15, the 'Tumbleweed-Snapshot-based-Release' model also has an interesting side effect when it comes to this part of getting a release published and marketed. Just as they share development models, both Tumbleweed and snapshot-based-releases have very similar core messages - "The latest of everything, each release". The major differences are the gap between releases and the method of maintenance after release. On each Release Day for the Regular Release, this ends up leaving us with relatively little exciting to talk about (Everything is already in Tumbleweed) and at the same time, way too much to talk about (the Changelog of 13.1 to 13.2 is insanely long and hard to filter down into exciting things to include in Release announcements) If snapshot-based-releases were to continue, we'd need to find a way to tackle that, and get people excited, talking about, and helping put together the release and it's marketing, something which is basically just the same as what we do every week, but maintained differently. But this is where my proposal for a Regular Release based on the SLE Sources comes into play. ( Video available at https://www.youtube.com/watch?v=BH99TSrfvq0 ) Our Regular Release has always been pulled in two directions, with some wanting it faster and more innovative, some wanting it slower and more stable. Tumbleweed has addressed the 'go faster' crowd - I think we have the *best* Rolling Distribution out there, and it's getting better Now we have the sources for SUSE Linux Enterprise we have an opportunity to build the *best* Stable Distribution out there. Something that really addresses the needs of those users who want a stable Linux distribution for 'real work', with Enterprise stability at it's core, with the community turning it into something exceptional. The best of both worlds, which is really something different from what everyone else has (Ubuntu LTS, CentOS) - and it's steps in that direction which will help us get new people involved to help work on it and make it even better going forward. I realise this proposal would mean the change of expectations for each openSUSE regular release - maybe we wouldn't upgrade every version of [insert software here] each release. I realise this is a huge change from the promise of 'The latest of everything, each release'. The individual teams of our project will have the opportunity to choose what goes into the new Regular Release and how often they want to upgrade it. With the clear division in direction between Tumbleweed and this new Regular Release, hopefully decisions about which versions make sense for inclusion when become easier for those teams. They'll know the kind of expectations our users have for either distribution, and be able to make informed judgement calls as to when to include whatever they want from the various upstream projects they maintain in openSUSE. In the case of the software provided in the shared SLE Sources, I also think we also have a lot of collective learning to do, as I think many of the fears regarding the 'age' of that software and their capabilities don't hold up under scrutiny (eg. the SLE Kernel gets a TON of backported features and patches) So while, of course snapshot-based-releases is a valid option, I'd rather see what we can make of this opportunity to build something better for openSUSE Project and our users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 06 of May 2015 00:41:09 Carlos E. R. wrote:

As a stable release user, I would be very excited by every new feature that I know is available in Tumbleweed that makes into Stable. And I would be very disappointed to find out that they will not be and that I have to wait another year for them.

One thing we should keep in mind is that openSUSE kernel maintenance doesn't work very well. You could read previous discussion on this topic for details. The short story is that unless we are lucky to pick a longterm kernel version (and we haven't been for quite long), upstream stable branch is closed even before openSUSE reaches its release and after that, only security bugs and small amount of functional fixes is backported into it. We do not have resources to do openSUSE kernel maintenance comparable to at least upstream stable branches. Piggybacking on SLE kernel maintenance allows to achieve much better maintenance with much less effort than anything else. That's why Evergreen 11.4 uses 3.0 kernel (SLE11-SP2 based) and Evergreen 13.1 is planned to use 3.12 kernel (SLE12 based - I consider a move to SLE12-SP1 but that's for a different discussion in other lists). Even if openSUSE provides features and drivers not provided or not supported by SLE (including the whole i586 architecture now), the result is still much better that anything else we can realistically think of. Of course, we can still do what we have been doing so far: take the latest released kernel available at the moment and do the minimum maintenance. But I can't help thinking it would be a pity if we didn't consider the opportunity to utilize the work behind SLE kernel. Perhaps having both might satisfy both types of users. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 6 May 2015 at 12:43, Guido Berhoerster wrote:

The main problem is that SLE and openSUSE have very different target audiences, the SLE kernel targets entreprise customers which tend to use enterprise hardware which is substantially different from consumer grade hardware with completely different lifecycles. Providing a kernel which lags years behind means (even with limited backports) that openSUSE releases likely cannot be used by a large share of endusers using more current consumer hardware (this is particularly an issue with consumer-grade laptops for which driver support is already problematic in the current situation). So I don't think this works at all and makes it much worse that what we have today, i.e. every 8 months a release containing the most current kernel at the time of the release even if its maintenance leaves much to be desired.

Are these statements that the "SLE Kernel doesn't have the hardware support required" based on fact, actual experience, or just theory based on assumptions? SUSE do lots of work for hardware enablement, there's already plenty in the current SLE 12 Kernel and more on the way with SLE 12 SP1. As we're not that far away from SLE 12 SP1, the current SLE 12 kernel is probably the 'oldest' it will ever be in regards to hardware enablement, so I'd be very curious to hear of actual examples of people who've downloaded (and patched) the current SLED 12 Kernel from the free trial SUSE offer and found bonefide 'this isn't good enough for my hardware' issues You also have to consider that SUSE is currently considering the possibility of not backporting fixes/features but actually changing the Kernel version they use in SLE 12 SP2 (assuming they can maintain API/ABI stability of course), so in our case with openSUSE we'd only have this kernel for about a year.. well maintained, with hardware enablement, and proper security patches.. sure if people can raise actual legitimate problems, I'm happy to hear them but I would prefer if the discussion continued on the basis of facts, not peoples theories about what does or doesn't work in the SLE codebase we now get to play with ;)

...

consider the opportunity to utilize the work behind SLE kernel. Perhaps having both might satisfy both types of users.

Perhaps, do you have the resources to support two kernels for each openSUSE release?

As Michal has pointed out, we don't really have the resources to fully/properly support the one kernel we're currently shipping with the current openSUSE Regular Release. So I think it's probably safe to say the answer to your question is 'no' -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Richard Brown [2015-05-06 13:45]:

On 6 May 2015 at 12:43, Guido Berhoerster wrote:

...

The main problem is that SLE and openSUSE have very different target audiences, the SLE kernel targets entreprise customers which tend to use enterprise hardware which is substantially different from consumer grade hardware with completely different lifecycles. Providing a kernel which lags years behind means (even with limited backports) that openSUSE releases likely cannot be used by a large share of endusers using more current consumer hardware (this is particularly an issue with consumer-grade laptops for which driver support is already problematic in the current situation). So I don't think this works at all and makes it much worse that what we have today, i.e. every 8 months a release containing the most current kernel at the time of the release even if its maintenance leaves much to be desired.

Are these statements that the "SLE Kernel doesn't have the hardware support required" based on fact, actual experience, or just theory based on assumptions?

SUSE do lots of work for hardware enablement, there's already plenty in the current SLE 12 Kernel and more on the way with SLE 12 SP1.

As we're not that far away from SLE 12 SP1, the current SLE 12 kernel is probably the 'oldest' it will ever be in regards to hardware enablement, so I'd be very curious to hear of actual examples of people who've downloaded (and patched) the current SLED 12 Kernel from the free trial SUSE offer and found bonefide 'this isn't good enough for my hardware' issues

Huh, are you actually serious? Unless SUSE is planning on backporting every single new driver that matters for endusers using cheap laptops then this is inevitably becomes an issue and moreso than today where we get at least _all_ the latest drivers every 8 months.

You also have to consider that SUSE is currently considering the possibility of not backporting fixes/features but actually changing the Kernel version they use in SLE 12 SP2 (assuming they can maintain API/ABI stability of course), so in our case with openSUSE we'd only have this kernel for about a year.. well maintained, with hardware enablement, and proper security patches.. sure if people can raise actual legitimate problems, I'm happy to hear them but I would prefer if the discussion continued on the basis of facts, not peoples theories about what does or doesn't work in the SLE codebase we now get to play with ;)

And I'd prefer if the discussion continued with less insinuations and handwaving of concerns. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Michal Kubecek [2015-05-06 14:46]:

On Wednesday 06 of May 2015 14:20:53 Guido Berhoerster wrote:

...

Huh, are you actually serious? Unless SUSE is planning on backporting every single new driver that matters for endusers using cheap laptops then this is inevitably becomes an issue and moreso than today where we get at least _all_ the latest drivers every 8 months.

The point is if you want "all the latest drivers", you can use Tumbleweed and have them every month or so. This discussion is rather

Sure, but I don't want to deal with the churn and occasional fallout on the laptop which I need for doing work. Of course *I* can run Kernel:stable (and have done so in the past because of lacking touchpad and graphics driver support) but the question is whether we only want to make a distro for openSUSE/SUSE developers or people who simply want towork on their laptops and cannot or do not want to deal with Tumbleweed.

about a stable, reliable and reasonably maintained distribution to provide for (e.g.) three years as an alternative for those who prefer the "stable" direction over the "latest and greatest" one.

Sure, that's great if you buy/lease a server today and want to run the same distro and kernel until it's written off. But for the desktop it is not so great, I have no strong opinion on a more stable userland middle layer but kernel/Mesa/X should be exempt from that and receive a refresh every 8 or maybe 12 months as they do today.

IMHO the main misunderstanding is that you base your comments on the assumption that the way openSUSE kernel has been maintained until now worked pretty well so that it would be best to go on with it. I don't believe this is the case and previous discussions (there were e.g. suggestions to move 13.1 to 3.12 kernel even within regular support period) show that I'm not the only one.

I do not assume that is has been working out well, but to me it sounds SUSE is scaling back even more in this area. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Robert Martens [2015-05-06 15:29]:

...

...

IMHO the main misunderstanding is that you base your comments on the assumption that the way openSUSE kernel has been maintained until now worked pretty well so that it would be best to go on with it. I don't believe this is the case and previous discussions (there were e.g. suggestions to move 13.1 to 3.12 kernel even within regular support period) show that I'm not the only one.

I do not assume that is has been working out well, but to me it sounds SUSE is scaling back even more in this area.

I’m curious about your last point there, what makes you think they are scaling back even more in this area?

AFAICT the kernel and X stack in openSUSE releases are currently maintained by SUSE staff. Especially for the kernel the current resources seem barely sufficient. The plan seems to be to cut these resources back by leveraging the same kernel/X stack that is already maintained in SLE. -- Guido Berhoerster -- 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 05/06/2015 06:16 AM, Guido Berhoerster wrote:

have no strong opinion on a more stable userland middle layer but kernel/Mesa/X should be exempt from that and receive a refresh every 8 or maybe 12 months as they do today.

I *strongly* disagree. Churn on kernel/Mesa/X is what gives users the most grief. SLE'S stack here is exceptionally stable, and the ABI-compatibility is part of why there are nvidia binaries for SLE. Leaving aside that I've been bitten by a recent Mesa/nouveau bug that made it through both Freedesktop.org & Tumbleweed's QA, I can say that firming up that part of the stack is going to solve *a lot* of problems for people who want a *stable* system. - -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com - ------------------------------------------------------------------------ SUSECon 2015: Register at susecon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVSigAAAoJEBs5UYhsRJAjYE8IAJyov80YZuDoef95km/q/aae DSC/jOcmKnoIurfJDvz3G4D8P+9ygD/QazaHtskbOGiR8EtaB0j46z9ponur+2Y2 mKMb/Q3do1yR2tb3nCtKUoUzceHQ3fIUUZsx5m/pH9ZomLhGcXoFK7rnkzqrg62n wPshE4mvMH0UNSwCbL/rgtF86G1BOMxAxtvD07iJGtIDUI2tWkAUckovF98ROFxQ Jxo5AF2MD1gpHo6714AwWZx+tpPxDDgMSKIXUQA8NEzWYxk/b5AibsdtzQ2+8Bf1 pdB/lznqWalymd69LJGHLPS7f7mLmObVG8PnMuUqQbOiAOxEUFm2X/ybS0zJZfE= =jfu9 -----END PGP SIGNATURE----- -- 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: SHA1 On 05/06/2015 08:46 AM, Michal Kubecek wrote:

On Wednesday 06 of May 2015 14:20:53 Guido Berhoerster wrote:

...

Huh, are you actually serious? Unless SUSE is planning on backporting every single new driver that matters for endusers using cheap laptops then this is inevitably becomes an issue and moreso than today where we get at least _all_ the latest drivers every 8 months.

The point is if you want "all the latest drivers", you can use Tumbleweed and have them every month or so.

Yes I get it. I either get to reboot my machine many times a week because a new kernel arrives in TW or I get the choice of not getting "new" drivers for years to come. Please consider the [possibility that there is a potentially a sizeable chunk of users that lie in between. As Guido pointed out, for many the "getting all 'new' drivers every 12 months" model appears to be working. What is being proposed is "get some 'new' drivers every 12 month". Lets face it, the chances of consumer product drivers being backported to the SLE base are slim. If the SLE kernel gets re-based every 2 years this implies that instead of "getting all 'new' drivers every 12 months" users end up with "getting some 'new' drivers every 24 months". A doubling of the waiting period and a reduction in features. Not a very compelling story, sorry. Additionally, SUSE is not committed to moving the kernel forward every other service pack (which has no committed release cycle either, just a rough time frame), rather, the "moving the kernel forward" is ad-hoc based on whatever suits the business considerations best.

This discussion is rather about a stable, reliable and reasonably maintained distribution to provide for (e.g.) three years as an alternative for those who prefer the "stable" direction over the "latest and greatest" one.

IMHO the main misunderstanding is that you base your comments on the assumption that the way openSUSE kernel has been maintained until now worked pretty well so that it would be best to go on with it. I don't believe this is the case and previous discussions (there were e.g. suggestions to move 13.1 to 3.12 kernel even within regular support period) show that I'm not the only one.

Well, I personally have encountered only few kernel bugs in our current release model. But then again I try to run on run off the mill hardware. The newer stuff where issues are encountered are the drivers for all the fancy thing one can plug into a USB port these days. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSl3LAAoJEE4FgL32d2UkLnsH/i+Z4QhA80nGwbF7tfHq50mW bYGxgGhnsaCe/hJiomIHidf0tbGXnxVvW552X9VQ1EBNXWTygwiWYCaqQGL2dXxx zqem7vUWkQrFdInbEXD/ibSSwzTi+Kyx4+1OLwASJ5QxPqrn26BSNc+EqWfmqYrJ vfMYibFZrnoWTj1AIz1BblMVaA4a4NIWGFYD0QuvaZy4JE9ZuE5S7i7P6xYy0+7r l749eMYXAuvtS6oqWRPDMRMD2NpbW4xRI4HoWRni3dMaQlGjvf4Qj+2nNbpqAI2V fp+efVPRkX2YVEWa+l4hNWogDlSJvzFU31w/9VuTeglLCwG10YWS1T4r59G3UnE= =OlLN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mercredi 06 mai 2015 à 08:29 -0500, Malcolm a écrit :

On Wed 06 May 2015 01:45:06 PM CDT, Richard Brown wrote:

<snip>

...

You also have to consider that SUSE is currently considering the possibility of not backporting fixes/features but actually changing the Kernel version they use in SLE 12 SP2 (assuming they can maintain API/ABI stability of course), so in our case with openSUSE we'd only have this kernel for about a year.. well maintained, with hardware enablement, and proper security patches.. sure if people can raise actual legitimate problems, I'm happy to hear them but I would prefer if the discussion continued on the basis of facts, not peoples theories about what does or doesn't work in the SLE codebase we now get to play with ;)

<snip>

Hi The only thing I've had to compile for the kernel was the it87 module for SLES 12, it is present for SLED 12...

This means it is part of kernel-*-extra package (which is only available on SLED and not on SLES). My proposal would be for an openSUSE kernel based on SLE kernel, we could have a single kernel package which would include the content on kernel + kernel-extra (if kernel team is fine with that)..

On this system HP ProBook 455 G1 since it's an AMD APU is to run the proprietary driver for boost states which means no secure boot.

Else no issues with HP 2000, HP ProBook 4330s and H ProBook 4440s with SLED 12 in my tests and using day to day...

Glad to read that ;) -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Le mercredi 13 mai 2015 à 08:55 +0200, Hans Witvliet a écrit :

On Wed, 2015-05-06 at 15:36 +0200, Frederic Crozat wrote:

...

Le mercredi 06 mai 2015 à 08:29 -0500, Malcolm a écrit :

...

On Wed 06 May 2015 01:45:06 PM CDT, Richard Brown wrote:

<snip>

...

You also have to consider that SUSE is currently considering the possibility of not backporting fixes/features but actually changing the Kernel version they use in SLE 12 SP2 (assuming they can maintain API/ABI stability of course), so in our case with openSUSE we'd only have this kernel for about a year.. well maintained, with hardware enablement, and proper security patches.. sure if people can raise actual legitimate problems, I'm happy to hear them but I would prefer if the discussion continued on the basis of facts, not peoples theories about what does or doesn't work in the SLE codebase we now get to play with ;)

<snip>

Hi The only thing I've had to compile for the kernel was the it87 module for SLES 12, it is present for SLED 12...

This means it is part of kernel-*-extra package (which is only available on SLED and not on SLES).

My proposal would be for an openSUSE kernel based on SLE kernel, we could have a single kernel package which would include the content on kernel + kernel-extra (if kernel team is fine with that)..

Converging would be nice, but I had the impression that (at least with sles) the kernel is lagging very much?

I remember once hearing (could be mistaken) that @maxfeld, they had to backport all sorts of recent kernel-bugfixes to ancient sles-kernels....

Again, it depends on your vision of "lagging" ;) Of course, sles kernel are getting a lot of backports (for instance, the btrfs stack in SLES kernel is way more recent than the one from vanilla 3.12) but OTOH, each new upstream kernel is introducing regressions, which are not always fixed (I remember reading about this on LWN recently but couldn't find the url). The point of using a "SLE" kernel would be to leverage work being done by SUSE kernel team for SLE in "less regression caused by new kernel" but still getting some new features. And kernel version updates are scheduled for some Service Packs in SLE (not just every service pack, unlike what we are currently doing on openSUSE regular release).. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On May 6, 2015 5:23:38 AM EDT, Michal Kubecek wrote:

On Wednesday 06 of May 2015 00:41:09 Carlos E. R. wrote:

...

As a stable release user, I would be very excited by every new

feature

...

that I know is available in Tumbleweed that makes into Stable. And I would be very disappointed to find out that they will not be and that I have to wait another year for them.

One thing we should keep in mind is that openSUSE kernel maintenance doesn't work very well. You could read previous discussion on this topic for details. The short story is that unless we are lucky to pick a longterm kernel version (and we haven't been for quite long), upstream stable branch is closed even before openSUSE reaches its release and after that, only security bugs and small amount of functional fixes is backported into it.

We do not have resources to do openSUSE kernel maintenance comparable to at least upstream stable branches. Piggybacking on SLE kernel maintenance allows to achieve much better maintenance with much less effort than anything else. That's why Evergreen 11.4 uses 3.0 kernel (SLE11-SP2 based) and Evergreen 13.1 is planned to use 3.12 kernel (SLE12 based - I consider a move to SLE12-SP1 but that's for a different discussion in other lists). Even if openSUSE provides features and drivers not provided or not supported by SLE (including the whole i586 architecture now), the result is still much better that anything else we can realistically think of.

Of course, we can still do what we have been doing so far: take the latest released kernel available at the moment and do the minimum maintenance. But I can't help thinking it would be a pity if we didn't consider the opportunity to utilize the work behind SLE kernel. Perhaps

having both might satisfy both types of users.

Michal Kubeček

From: http://en.m.wikipedia.org/wiki/SUSE_Linux_distributions There was a 2 1/2 year period without a major SLE kernel release recently Feb 2012-kernel 3.0 (and still used for SLE 11.3) Oct 2014-kernel 3.12 Assume there was a summer 2014 opensuse release. What are you proposing as relates to leveraging the SLE kernel? Release with 3.0 then have an opensuse "service pack" to get the 3.12 kernel out? If not, will SLE even support 3.0 through the lifetime of a summer 2014 opensuse release? I.e.. until fall 2016 I assume. When in 2014 would the SLE 3.12 kernel have been available to opensuse? Maybe the opensuse release could have been delayed to wait for it? Btw: am I right that Evergreen leveraged the SLE 3.0 kernel and plans to leverage the 3.12 kernel? Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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: SHA1 On 05/06/2015 05:23 AM, Michal Kubecek wrote:

On Wednesday 06 of May 2015 00:41:09 Carlos E. R. wrote:

...

As a stable release user, I would be very excited by every new feature that I know is available in Tumbleweed that makes into Stable. And I would be very disappointed to find out that they will not be and that I have to wait another year for them.

One thing we should keep in mind is that openSUSE kernel maintenance doesn't work very well. You could read previous discussion on this topic for details. The short story is that unless we are lucky to pick a longterm kernel version (and we haven't been for quite long), upstream stable branch is closed even before openSUSE reaches its release and after that, only security bugs and small amount of functional fixes is backported into it.

We do not have resources to do openSUSE kernel maintenance comparable to at least upstream stable branches. Piggybacking on SLE kernel maintenance allows to achieve much better maintenance with much less effort than anything else. That's why Evergreen 11.4 uses 3.0 kernel (SLE11-SP2 based) and Evergreen 13.1 is planned to use 3.12 kernel (SLE12 based - I consider a move to SLE12-SP1 but that's for a different discussion in other lists). Even if openSUSE provides features and drivers not provided or not supported by SLE (including the whole i586 architecture now), the result is still much better that anything else we can realistically think of.

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation. Thus for x86 we would end up with a kernel that has a very large number of patches, is based on an older kernel version and will be difficult for others to work with due to the large number of patches if an issue arises that is specific to x86. Plus the chances of getting help from upstream on this kernel are even slimmer than with the approach we take today. I think that for all features that SLE supports we would end up with a better kernel binary than we have in openSUSE today. However for everything else, as stated above I think the argument doesn't apply. Last but not least a backport of a driver for the latest whiz-bang USB plug in gizmo is not going to happen if it is of no interest for SLE. Then we end up in a situation where the upstream kernel supports the feature but openSUSE users cannot access it because it will not be backported because it is of no interest to SLE. Thus, just considering the kernel there are many unanswered questions. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSlgcAAoJEE4FgL32d2UkR1IH/3S3ytnnzUTguV9jIzdehOks +VgNb7H3lKhggTJx+f13/d13twvtQQ/kfv5Ii8XZfscGHFq4Tb2Ly0UMjWMOLG4n vPJmlZxMnD8jdvJBQnDsTXQ5PpfeaxRTufCm4dHRGm8heJ6A7t8J4FXto3vx8GMo qpNSCk4v4ut1dRkMenZOfu4Po/GH9QzO0RV7cIAPcznU04kZK4lobiFD/gvNrvmW 2mjY4MTrMp9ATf1xEzpEu5qDWfgN/J31WLMdeYEItlZVVXizQFNnhftVonv/Now2 QorvGZqStM3M2N+8tl1xDxhmGuelFgjHo0N8eN4LKWFceO+K/MO5F1IkyKHDApw= =O9jw -----END PGP SIGNATURE----- -- 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: SHA1 On 05/06/2015 02:35 PM, Michal Kubecek wrote:

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

Well, I still use a netbook every now and then that I like to update to get security fixes etc.

Try to answer honestly: how much testing and QA did current (13.2 or Tumbleweed) openSUSE kernel get on i586?

Enough that the upgrade from 13.1 to 13.2 on the netbook worked flawlessly. Network, disk and everything I expect works.

How much chance of getting attention to an i586-specific bug would you get? Do you really believe that given the circumstances and popularity of i586 among kernel developers, the state of i586 kernel would be significantly worse if we based openSUSE kernel on SLE (compared to current state)?

I believe that if there were an i586 specific bug and I have a recent enough kernel I can get help upstream. However, with a kernel that is based on an older release and carries a lot of patches that will be more difficult. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSnVQAAoJEE4FgL32d2UkJ3cIAKaQE2XE8RJWHk8x22QFIeOE sHFn1yEwG0y9BCVn39b4hs1Vf3/QBMaPh/NFPbWi+I6G9all3JZQVIkKtLcYBpAv hRvuCUBFTVd0A5QHg56D9z9n5JXIi25csQy/73pt/GTojRIp/ns3aTAVMtk3pDR4 GKN+YnKS03QALX8XF8gu013/nC3K0xxSaglA8vAhAZ/YyQlwjVspmcj34FKIPqMX 3NzFdNVG3vlrdV54apd+khQbYNpVpKrh35p+gwILEbcMaP77t9atayVZi4/ntR81 HsMhBr/2VNLbSrf0lBaloE4WUcIuFIzD3FHyoCGWG2on0coj9OT7AD45UoVGDfs= =1wpS -----END PGP SIGNATURE----- -- 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: SHA1 On 05/06/2015 05:14 PM, Stephan Kulow wrote:

Am 06.05.2015 um 22:10 schrieb Robert Schweikert:

...

Well, I still use a netbook every now and then that I like to update to get security fixes etc.

Robert, I think I heard you say in The Haag that openSUSE needs to stop trying to be everything for everyone and concentrate on a specific user group.

No, sorry you misheard. This statement only concerned the marketing message, not the nature of the way we build our distributions or the overall freedom of letting people do what they like and how they want to scratch their itch. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSraMAAoJEE4FgL32d2UkO8oH/RQ5PCVtRAnxZQKomOlb/uHR qdEeUxltnOix1w50GappMbkYzkwUf6Inf5CcnmIlFfR+E6++/U26d2d0mtQhFOrg 6RDi+t6q6zQKdFqSAzBe4aL+uB/xfMPnwAxAQzjx5WMrm6ULPejltQoOdxNkVN2G b4Dg5Klhu/Xz+Y0dxm0KD6eSG797XUOS7STcOExIaMAIOV4BHH0sRFb7lfpW6JhD +Yt9Z6CFlh0r5BjOlalB8phkPziQJRxRvklFmTaoxtmu9OPIbhHn0Pt0BPCfJtRd 3zI6ejNOtSysdSJ9u9H/YVP31ajj0i/WVElpFr4R/OOV91Z2CXKIqWKcINeOd9E= =MOJG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 06.05.2015 um 23:14 schrieb Stephan Kulow:

specific user group. We can move i586 support into a ports project - just as we have arm7 and ppc and you can be maintainer. But it really shouldn't be in our focus in 2015.

And even though I'm one of the old farts who still has quite some i686 hardware around (and in active use), i have to heartily agree with Stephan here :-) now if we only could also do away the same with that ppc64le stuff that's polluting my obs mailbox with crazy buildfailures all the time... :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 07.05.2015 um 16:12 schrieb Stephan Kulow:

On 07.05.2015 14:49, Stefan Seyfried wrote:

...

now if we only could also do away the same with that ppc64le stuff that's polluting my obs mailbox with crazy buildfailures all the time... :-)

Is it really that bad? I don't see too any ppc64le specific build failures in stagings at least.

No, it's always the same multimedia packages that probably nobody is ever going to use on such niche hardware anyway :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Stefan Seyfried wrote:

Am 06.05.2015 um 23:14 schrieb Stephan Kulow:

...

specific user group. We can move i586 support into a ports project - just as we have arm7 and ppc and you can be maintainer. But it really shouldn't be in our focus in 2015.

And even though I'm one of the old farts who still has quite some i686 hardware around (and in active use), i have to heartily agree with Stephan here :-)

Ditto and ditto. We still have an ancient HP Proliant G1 chugging away in a corner somewhere. One of these days it'll be virtualized, but as long as it runs, there's no big need. -- Per Jessen, Zürich (20.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- 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: SHA1 On 05/06/2015 06:00 PM, Michal Kubecek wrote:

On Wed, May 06, 2015 at 04:10:56PM -0400, Robert Schweikert wrote:

...

On 05/06/2015 02:35 PM, Michal Kubecek wrote:

...

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

Well, I still use a netbook every now and then that I like to update to get security fixes etc.

And you would (unless we are brave enough to drop i586), they would just be less tested than on x86_64. Which wouldn't really be that much different from today's 13.2 or Tumbleweed. Out of curiosity... the low-end netbook I bought in summer 2010 has a 64-bit processor; how old is yours that it doesn't?

I have no idea. It was one of the first Inspiron 10 that shipped with another distro pre-loaded and help me avoid paying the proprietary pretent OS tax. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSrfMAAoJEE4FgL32d2Uk4vgIAL7DxsJ6K/HvWwkQxtVyJrLE 9WD3aoremwz1M4FwWUoFwVx118hSV6gVpFveOKx8dXSeNrvgeTmc2WAvSHTRwF0G w2Mt3xIv4R2Cz7V7YdqjCcMr5pVTRP7utSFN0RZwJ+fW4P0InF7Enp6XHL7Ef0wl QgL1ObcLgs5tcBlzDWN5opRel5XwfTHAZTqEgoe1Zc8EWZDrGnWuaun8l62azvTa mlgSc9fcplUEjZLB5MjeJ4HmfezsO/I4v/3z3jsG+Zu9YkzydLKP3h/MOEZvnsMP l6YIE0a38eLIWjQbg5YA867aDNC63qrV5xixeXkx6p+vkCeizMBPQXyc37WxUiw= =n+KU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 07 of May 2015 07:29:32 Roger Oberholtzer wrote:

I understand the advantage of focusing on one architecture. But is 32-bit really dead? I say: not quite yet...

Well it definitely is not dead. :-( I'm afraid 10 years from now, I might still be reading e-mails explaining we can't get rid of i586 (together with those explaining we can't get rid of ifconfig).

As a minimum, it might be a good idea to decide to eliminate it at some reasonable point in the future, and make an official announcement of that. This will let people plan the transition. The official announcement and a time schedule will let people convince the powers that be that resources are needed within that time frame to resolve any local issues.

I should make one thing straight: I did _not_ suggest next openSUSE release shouldn't provide i586 architecture. All I did want to say was that the fact that SLE12 is not provided for (and supported on) i586 shouldn't be seen as relevant for the discussion if we want to base next (or any future) openSUSE release on SLE packages. And that's for the reasons I already mentioned: it does not stop us from providing i586 openSUSE and if we do, i586 openSUSE wouldn't get significantly less testing, attention and support than recent releases had. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2015-05-07 09:44, Michal Kubecek wrote:

On Thursday 07 of May 2015 07:29:32 Roger Oberholtzer wrote:

...

I understand the advantage of focusing on one architecture. But is 32-bit really dead? I say: not quite yet...

Well it definitely is not dead. :-( I'm afraid 10 years from now, I might still be reading e-mails explaining we can't get rid of i586 (together with those explaining we can't get rid of ifconfig).

Software is cheap(er) to substitute, as there is no tax (in both a legal and a practical sense) on "disposing" of electrons. Fedora has already gotten rid of ifconfig by default, and in post-13.2 TW, it finally is gone too by default. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2015-05-07 11:39, Felix Miata wrote:

I still have it in TW20150430, and good thing too. I have yet to discover an equivalent to 'ifconfig -a'

ip a -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 2015-05-07 12:08, Felix Miata wrote:

Jan Engelhardt composed on 2015-05-07 11:46 (UTC+0200):

...

Felix Miata wrote:

...

...

I still have it in TW20150430, and good thing too. I have yet to discover an equivalent to 'ifconfig -a'

...

ip a [== ip addr]

Why is that missing from the usage message and the man page?

Is it? $ ip Usage: ip [ OPTIONS ] OBJECT { COMMAND | help } where OBJECT := { link | addr | addrlabel | route ... The only nitpick bug there is that it ought to say [ COMMAND | help ] instead of { COMMAND | help }. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 7 May 2015 at 13:00, Felix Miata wrote:

Nothing in the entirety of the usage message says anything about "a", same omission as the man page. Mere mortals don't all know what man page writers and programmers assume they know.

"ip a" is short for "ip addr" which is in the man page Stop being so pedantic ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 07 May 2015, 18:02:19 +0200, Felix Miata wrote:

Richard Brown composed on 2015-05-07 13:21 (UTC+0200):

...

Felix Miata wrote:

...

...

Nothing in the entirety of the usage message says anything about "a", same omission as the man page. Mere mortals don't all know what man page writers and programmers assume they know.

...

"ip a" is short for "ip addr" which is in the man page

Where in the man page exactly? If it was apparent I wouldn't have had reason to ask.

Quoted from "man 8 ip": The names of all objects may be written in full or abbreviated form, for example address can be abbreviated as addr or just a. And, for further information try "man 8 ip-address" (from SEE ALSO). HTH, cheers. l8er manfred

Petr Gajdos composed on 2015-05-07 13:48 (UTC+0200):

On Thu, May 07, 2015 at 07:00:35AM -0400, Felix Miata wrote:

...

Nothing in the entirety of the usage message says anything about "a", same omission as the man page. Mere mortals don't all know what man page writers and programmers assume they know.

man 8 ip:

"The names of all objects may be written in full or abbreviated form, for exampe address can be abbreviated as addr or just a."

That doesn't look anything like a translation of 'ifconfig -a(ll)' to me. It's like most man pages, void of examples that give some meaning to the list of possible options, and reduce need to Google for a usable explanation or HOWTO. -- "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 Thu, 7 May 2015 12:08, Felix Miata wrote:

Jan Engelhardt composed on 2015-05-07 11:46 (UTC+0200):

...

Felix Miata wrote:

...

...

I still have it in TW20150430, and good thing too. I have yet to discover an equivalent to 'ifconfig -a'

...

ip a

Why is that missing from the usage message and the man page? Most people are not clairvoyant with eidetic memory.

Quote from the "man 8 ip", see the sentence in the middle? [quote] xfrm - manage IPSec policies. The names of all objects may be written in full or abbreviated form, f.e. address is abbreviated as addr or just a. COMMAND Specifies the action to perform on the object. The set of possible actions depends on the object type. [/quote] and TBH, I've overlooked it, too. Nice to know. Now, for the question: "ifconfig -a" had some statistics, too, how do I get them with "ip"? Answer: "ip -s link". Use more than one "-s" to give more statistics - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

On Thursday 07 of May 2015 12:25:45 Yamaban wrote:

...

Now, for the question: "ifconfig -a" had some statistics, too, how do I get them with "ip"?

Answer: "ip -s link". Use more than one "-s" to give more statistics

Recent versions also support "ip -s addr show" so you can have both addresses and statistics at once.

Must be more like brand new versions - I don't get any stats when I tried it on 13.2. -- Per Jessen, Zürich (20.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek writes:

On Thursday 07 of May 2015 17:48:27 Per Jessen wrote:

...

Michal Kubecek wrote:

...

Recent versions also support "ip -s addr show" so you can have both addresses and statistics at once.

Must be more like brand new versions - I don't get any stats when I tried it on 13.2.

Just checked the git: should be there since iproute2 3.17.

Only ip li, not ip ad. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, 7 May 2015 17:57, Michal Kubecek wrote:

On Thursday 07 of May 2015 17:48:27 Per Jessen wrote:

...

Michal Kubecek wrote:

...

Recent versions also support "ip -s addr show" so you can have both addresses and statistics at once.

Must be more like brand new versions - I don't get any stats when I tried it on 13.2.

Just checked the git: should be there since iproute2 3.17.

FYI: Versions of iproute2 in openSUSE: OSS 13.2 offical update: 3.16, thats a no for plain 13.2 + upd. OSS 13.1 offical release: 3.9.0 Michal Kubecek has 3.19 in his "home" repo [1] Factory is on version 4.0, from "security:netfilter" [2] repo. Version 4.0 is available there for Factory, 13.2, 13.1, SLE-12. [1] http://download.opensuse.org/repositories/home:/mkubecek:/utils/openSUSE_13.... [2] http://download.opensuse.org/repositories/security:/netfilter/openSUSE_13.1/ - Yamaban. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Donnerstag 07 Mai 2015, 09:44:18 schrieb Michal Kubecek:

On Thursday 07 of May 2015 07:29:32 Roger Oberholtzer wrote:

...

I understand the advantage of focusing on one architecture. But is 32-bit really dead? I say: not quite yet...

Well it definitely is not dead. :-( I'm afraid 10 years from now, I might still be reading e-mails explaining we can't get rid of i586 (together with those explaining we can't get rid of ifconfig).

my 2 cents and factoids: I'm running X86_64 where possible, but on my end user desktop and laptop I do have quite a few applications (games) that are distributed in binary form and only as 32bit, so please do NOT eliminate the ability of running 32bit apps, whatever else you guys decide about the 32bit architectures. cheers MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

As long as it's user space you can run such legacy 32bit code on an otherwise 64bit system just fine. That's what the *-32bit packages are for. So for this use case there is no need for an i586 installation medium.

I think all the issues would be in user space. We do have a device driver (https://build.opensuse.org/package/show/home:rogeroberholtzer:kernel/univers...) that maps the VME bus into an application's memory. I have no idea if that driver is 32-bit safe. This is used on systems where we run a JEOS-type diskless openSUSE (built with kiwi) that boot with PXE on VME-based PCs. It provides network access to a VME-based real-time measurement system. Like I said, we use openSUSE in adventurous ways. We would have to install both the 64-bit and 32-bit versions of libraries and development packages that we use. Seems a recipe for mistakes. We need a plan... -- Roger Oberholtzer-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek composed on 2015-05-06 20:35 (UTC+0200):

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

Try to answer honestly: how much testing and QA did current (13.2 or Tumbleweed) openSUSE kernel get on i586?

I have many test installations. Most by far are 32 bit regardless of CPU type. At least 3 do not support SSE2.

How much chance of getting attention to an i586-specific bug would you get? Do you really believe that given the circumstances and popularity of i586 among kernel developers, the state of i586 kernel would be significantly worse if we based openSUSE kernel on SLE (compared to current state)? I don't think so - and even if I did, I don't believe it would outweigh the difference on x86_64.

I find 64 bit chronically annoying, and so use it on few machines even capable of using it. Most of mine are not. The one I most use, up 24/7 and I write this with is on i586 even though it's an E7600 with 4G RAM and using RAID. 1-most of my machines have less than 4G RAM, and many don't support more than 1GB, which is ample for most users for email, shopping, banking, youtube, etc. 2-64 bit installations take more disk space, which in turn means updates require more time and bandwidth for the duplicative required -32bit packages 3-last I checked specifically, zypper still offered no option to not clutter search results with i586 packages on 64 bit installations 4-whatever speed advantage 64 bit may have over 32 bit has never become apparent to me 5-need for >4G RAM has yet to manifest here 6-killing off 32 bit means inducing otherwise premature migration of working machines into landfills, econeg. -- "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

Michal Kubecek composed on 2015-05-07 00:27 (UTC+0200):

...

6-killing off 32 bit means inducing otherwise premature migration of working machines into landfills, econeg.

I wouldn't be so sure about that, old machines tend to be less energy efficient.

It isn't just about cost to use. It's also about raw materials depletion and other costs to manufacture and ship, and about the relationships among them. It makes little sense to incur cost to acquire greater efficiency if actual use is low making payback negative or long. Increasing MPG from 15MPG to 30MPG will not recover a $20,000 investment through fuel cost savings at North American fuel prices if driving only 3,300 miles/year. Newer == better is a theory that doesn't necessarily work out as expected. Energy Star has been around a long time, well over a decade, maybe two by now. Suspend and sleep are old too. Assuming all else equal, new that is 4X as fast and 2X as efficient probably still consumes something approaching 2X the power of the baseline. 20X as fast is unlikely to be 20X as efficient. I've been measuring and recording actual consumption by my own machines for years. They vary all over the place. Age is a poor predictor. The biggest indicator of deviation from average electrical consumption is the size of gfxchip heat sink, and fan vs. no fan, but case size and CPU cooling count too, even need for heat sinks on RAM. Small cases have fewer components and usually less capable power supplies that run at higher fraction of capability, which commonly translates to higher net efficiency. Old machines with tiny or no gfxchip heat sink and no fan aren't big power consumers or heat producers. Newer may well use less electricity, but there's nothing like a guarantee total cost will be less. What ain't broke rarely needs fixin. :-) -- "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 05/07/2015 12:39 AM, Michal Kubecek wrote:

On Wednesday 06 of May 2015 20:24:23 Felix Miata wrote:

...

Newer may well use less electricity, but there's nothing like a guarantee total cost will be less.

No guarantee, sure. I just wanted to point out that replacing an old machine is not necessarily a bad thing from the "eco" point of view.

I volunteer one day a week for a non-profit organization in Kansas City (www.connectingforgood.org). This group accepts donations from anybody and refurbishes the computers that are suitable. If a desktop has a CPU > Pentium 4, we ensure that it has at least 2 GB RAM and an 80 GB hard drive. After installation of Windows 7 Pro, the machine is sold to low-income people for $75. That includes everything but speakers. Those are rarely donated. If the user wants a full Office license, that is an additional $20. Everything has a one-year, no questions asked, warranty. All computer equipment that is unsuitable for refurbishing is properly recycled so that very little ends up in a landfill. New may be more economical to operate, but the price may be too high for some users. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, May 6, 2015 at 5:43 PM, Felix Miata wrote:

2-64 bit installations take more disk space, which in turn means updates require more time and bandwidth for the duplicative required -32bit packages

The -32bit packages are not required..(maybe except a few small ones) , the problem is that something "recommends" them, either in the patterns or spec files.. (I have no looked where that comes from)

3-last I checked specifically, zypper still offered no option to not clutter search results with i586 packages on 64 bit installations

4-whatever speed advantage 64 bit may have over 32 bit has never become apparent to me

A good easy to test example is openSSL.. where the most commonly used algorithms are significantly faster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2015-05-06 20:35, Michal Kubecek wrote:

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

One does not even need to try hard. http://www.ebay.de/itm/IBM-eServer-xSeries-x-335-2-x-XEON-2-8GHz-CD-/140672266437?pt=LH_DefaultDomain_77&hash=item20c0b870c5 These kinds of servers are somewhat popular with the gaming community (at least the guys I am in contact with) to host game daemons at gatherings. As you can see, these are quite the vintage systems — previously used systems that other entities have decommissioned. However, they still pack enough punch per watt to be not written off by their current new owners.

Try to answer honestly: how much testing and QA did current (13.2 or Tumbleweed) openSUSE kernel get on i586?

I can tell by experience of administering aforementioned IBM models: sufficient.

How much chance of getting attention to an i586-specific bug would you get?

i586 is so well-establlished that I do not expect any more issues with the platform.

Do you really believe that given the circumstances and popularity of i586 among kernel developers, the state of i586 kernel would be significantly worse if we based openSUSE kernel on SLE (compared to current state)?

In case of i586, a SLE kernel might do. But since openSUSE produces a $modern kernel _anyway_, snatching of the i586 build result for said modern kernel is cheap. coolo's idea of placing i586 onto the ports backburner sounds acceptable. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

On Thu, May 07, 2015 at 12:01:09AM +0200, Jan Engelhardt wrote:

...

On Wednesday 2015-05-06 20:35, Michal Kubecek wrote:

...

haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

One does not even need to try hard.

http://www.ebay.de/itm/IBM-eServer-xSeries-x-335-2-x-XEON-2-8GHz-CD-/140672266437?pt=LH_DefaultDomain_77&hash=item20c0b870c5

OK, I should have said it explicitely: I meant a new one. I guess if I wanted, I could still get a ZX Spectrum, maybe even ZX-81.

Sure, what are you offering, I'm sure I've got a couple in the attic still :-) Anyway, I thought you could still get some 32-bit SoC for the embedded and mini market - AMD Geode comes to mind, but I don't know if they even still make that. -- Per Jessen, Zürich (20.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Michal Kubecek wrote:

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

A 32-bit system can run far more postfix and dovecot processes than a 64bit with the same amount of memory. -- Per Jessen, Zürich (20.0°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Thursday 2015-05-07 17:22, Per Jessen wrote:

...

Michal Kubecek wrote:

...

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

A 32-bit system can run far more postfix and dovecot processes than a 64bit with the same amount of memory.

If you want to run that many postfixes, you would rather want to use a X32 userspace, and not a i586 one.

Completely agree, but I have yet to try that out, one of these days I will. I can't help wondering if there are any issues in 32bit apps communicatiung with 64bit apps? E.g. a 32bit postfix talking to a 64bit mysql? -- Per Jessen, Zürich (20.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, May 7, 2015 at 12:44 PM, Per Jessen wrote:

Jan Engelhardt wrote:

...

On Thursday 2015-05-07 17:22, Per Jessen wrote:

...

Michal Kubecek wrote:

...

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

A 32-bit system can run far more postfix and dovecot processes than a 64bit with the same amount of memory.

If you want to run that many postfixes, you would rather want to use a X32 userspace, and not a i586 one.

Completely agree, but I have yet to try that out, one of these days I will. I can't help wondering if there are any issues in 32bit apps communicatiung with 64bit apps? E.g. a 32bit postfix talking to a 64bit mysql?

Unless one of those components is doing something terrible wrong, there should be no problem.. in your example, a postfix plugin is probably sending SQL queries to the database using the mysql client library. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday 07 of May 2015 17:33:05 Per Jessen wrote:

Michal Kubecek wrote:

...

On Wed, May 06, 2015 at 02:06:20PM -0400, Robert Schweikert wrote:

...

Well, I am not convinced about this. Especially that SLE no longer has an x86 implementation.

I'm going to say something that will be very unpopular but I feel it really needs to be said. Should we really care so much about i586? I don't have any 32-bit system since something like 2008, I definitely haven't seen any 32-bit x86 CPU in usual e-shops for at least 5 years and I'm not sure I would be able to buy one today if I tried hard.

Specifically, what would be gained by dropping the i586 build? I still have use-cases for 32bit, but I could just remain on the last release with support.

I already tried to explain it once but, OK, again: I did _not_ propose to drop i586 build. I just wanted to say that the fact that SLE is not released for and supported on i586 shouldn't be seen as an argument against basing next (or any future) openSUSE release on SLE packages. Michal Kubecek -- 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: SHA1 On 05/05/2015 05:11 PM, Richard Brown wrote:

On 5 May 2015 at 21:40, Martin Schlander wrote:

...

It was also the first release based on the "new" factory/tumbleweed, with a very short testing phase (two devel releases with 2-3 weeks between) and iirc the roadmap itself was published very late.

Secondly, openSUSE releases shouldn't need as many testers/much testing as before, with Tumbleweed already being fairly well tested by a decent number of people running it full-time. At least I thought that was the idea.

The whole process of Tumbleweed based stable releases just needs a few small adjustments, to work well imo. (A roadmap, a slightly longer window to test things, a fixed 12 month release cycle, 26 months of lifetime (2 releases+2 months) would be a very good start).

I understand where you're coming from, but I think there are a few things I'd like you to consider

The 13.2 release required a large amount of work from a small number of people to make it a success. From an Engineering perspective it was 'just' a Tumbleweed snapshot, but from a Marketing, Branding, 'actually getting a release out of the door' perspective, it required as much work as any other software release. For 13.2 this fell on the shoulders of a tiny handful of people. The reality is that Tumbleweed has captured the excitement of a huge portion of our current contributing community, and grown it greatly, and that's great, but it does have the side effect of leaving less enthusiasm and less people to work on the Regular Release. As was discussed at the Project Meeting at oSC 15, the 'Tumbleweed-Snapshot-based-Release' model also has an interesting side effect when it comes to this part of getting a release published and marketed. Just as they share development models, both Tumbleweed and snapshot-based-releases have very similar core messages - "The latest of everything, each release". The major differences are the gap between releases and the method of maintenance after release. On each Release Day for the Regular Release, this ends up leaving us with relatively little exciting to talk about (Everything is already in Tumbleweed) and at the same time, way too much to talk about (the Changelog of 13.1 to 13.2 is insanely long and hard to filter down into exciting things to include in Release announcements) If snapshot-based-releases were to continue, we'd need to find a way to tackle that, and get people excited, talking about, and helping put together the release and it's marketing, something which is basically just the same as what we do every week, but maintained differently.

Correct, we need a better approach to the marketing of the snapshot based releases and we need more people contributing to the snapshot based releases.

But this is where my proposal for a Regular Release based on the SLE Sources comes into play. ( Video available at https://www.youtube.com/watch?v=BH99TSrfvq0 )

Switching the base of the regular release is not a solution to either of our most pressing problems (mentioned above), better marketing for regular releases and more people involvement in the creation of the regular releases. Re-basing the regular release serves a different purpose and thus without addressing the actual issues we face concerning regular releases we will inevitably end up in the same place whether the release is based on SLE sources or on snapshots. The idea of "base it in something new and they will come" is a fallacy. What we really ought to figure out is how to solve the other problems fist. Then consider if re-basing is what we want to do or if we even want a third release with the distro based on SLE sources replacing Evergreen. I don't know. What I do know is that the actual issues surrounding the regular release (a quote from your message): "The 13.2 release required a large amount of work from a small number of people to make it a success." will not be resolved just because we pick a different base. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSlUKAAoJEE4FgL32d2UkRvcH/Rv581fMb+M7pR0uaZzfmiSM E7WYmnFMQb65S67/PAupzr79U/fRQQaWU8ORvSI6tkR06Dvz9z1QpiQC5408Ha9+ C1Lg54VU84SO6l73e8uMpbk7NwcOj0ExCsocgc3oSaAGvp+mXTDBdNP7Z86STby+ 1mSmK8OzC7ZTb2fRDFs2YLppKJgOXOLWtbYQ3ri7pU2pwLnc94NMZ6QpTCkwpcKv Dc/q7Ar4Kv4mkuPiUWW8kHoj4vZYcDebo5uuSUZbRaKh3xpZ7YUnVUallyQJKgfB 98FdqDqMrUjlOmHoSGgAB1LhWE9JLnbVziCz9/cfR6zVjXSbd6V3Md/MHpvgJJA= =h52R -----END PGP SIGNATURE----- -- 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: SHA1 On 05/06/2015 02:53 PM, Michal Kubecek wrote:

On Wed, May 06, 2015 at 01:53:14PM -0400, Robert Schweikert wrote:

...

Correct, we need a better approach to the marketing of the snapshot based releases

I don't think marketing is the problem. The problem is that with the change of approach to Tumbleweed and Factory, current Tumbleweed attracted substantial part of those openSUSE users who focus on new versions and new features. As a result of these changes, 13.2 lost big part of its "added value" and became less attractive. The way I understand Richard's arguments, he believes one way to regain some of the sense to the releases is to move them more away from the Tumbleweed so that they could target a different group of users, in particular group openSUSE failed to target for long time. And I agree with him.

It would be even nicer if we could do three distributions: Tumbleweed, something similar to openSUSE <= 13.1 and some "LTS" version (possibly SLE based). But I'm afraid we don't have resources to do all three and there is no easy way to change that fact in short timeframe.

...

and we need more people contributing to the snapshot based releases. ... "The 13.2 release required a large amount of work from a small number of people to make it a success."

will not be resolved just because we pick a different base.

I disagree. People have free will, they won't come just because we need them. They will if we do something to attract them. I believe offering a solution in the area where we have been failing to provide one for years is more likely to attract users and contributors than offering two versions of a distribution that are not too far from each other.

We shall see. Bottom line is that someone has to do the work. Given that we've had like 5 contributors, if that many to get a regular release out the door it will probably be up to those 5 to decide what hey want to do. Those who do, decide. Once the decision is made and we have something and there is sufficient movement to do something else it will happen, if not it won't . So far I do not think there has been a big rush to actually build packages from the released SLE sources. Maybe this also says something about the overall "excitement" over this event ;) . Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSndFAAoJEE4FgL32d2Uk/qkH/1Mtrxw2j6pJ+5NhVoZMJcqO WK0+Z9nSYQHoPatYmGXa5UEzm6n2zrZky9QZCw1yI482QMgM+cFTJY2tR9GSECqV fiD92gh3U3q0IT7VFstOQ6KCTVcfmUXSbBRc7rcsyJagqU3zQLLBa5cqh+97mfME Lw8HECfeBUvhVb1cDHOUxDehi7Bz+03e31GSq/5E736dR6H9oiYtrxpcLHu/5DGU 6xlct3eGzUFYuxKcwbf/YleyONRHjf8IRfWJUbKOkLymNGX7Cjd99tyF2Vwo1FWK GTsUrUhEKw3JRCQydiobSnDdWre4agU/XTpc3iuaKwRgE+B9amPV3nIRALVafiE= =4wXH -----END PGP SIGNATURE----- -- 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: SHA1 On 05/06/2015 06:34 PM, Christian Boltz wrote:

Hello,

Am Mittwoch, 6. Mai 2015 schrieb Robert Schweikert:

...

We shall see.

Bottom line is that someone has to do the work. Given that we've had like 5 contributors, if that many to get a regular release out the door it will probably be up to those 5 to decide what hey want to do. Those who do, decide.

No objection here, but please keep in mind that replacing the base packages with the SLE packages more or less invalidates the testing done in/with tumbleweed. So if we decide to release 13.3 with the SLE packages as base, we'll need to do quite some additional testing.

In exchange, we get the testing done for SLE and easier/shared maintenance.

...

So far I do not think there has been a big rush to actually build packages from the released SLE sources. Maybe this also says something about the overall "excitement" over this event ;) .

Maybe. It could also be that people just need some time to do that or are still busy with the things that piled up on their desk while they were at oSC ;-)

I'd also guess that most people here don't know what exactly is in SLES and SLED (speaking of package list, versions and backported patches) and how they differ from openSUSE.

If you or someone else has a list with the major differences between SLE* and openSUSE, it would be more than welcome.

I heard at oSC that the SLE* DVD images are available for download somewhere[tm] to test SLE* (does someone have the download link at hand?), but that's also something the average factory contributor might not know.

download.suse.com One can get the iso without requesting an eval code. Install, run as long as you want without updates. Later, RObert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVSrUAAAoJEE4FgL32d2Uk/T0IAI+EOR1klwR6czedXcND1RUt YElDiBtHNBoDBdpHBgaHvJtkC1TDM/oRQhp8WQ+b1lNm4YUlmHOGeae0n2tXYv57 rQTan5wtWE+SBfYId71vykIHdf7I36fRQT4rz4dMG5INzqDY8A/9bICH5k4rI/oK JhrvRBLAW4Q5RDXVjqk0pukzzvZEH4C+ZqvW7bNNLUBsDyNyv83vabm6alT/dbQY +/1bZqTNrD3mPIL8S7VQMl6pWur7XSaXQ4JstMbqzTChczuajd3XcKd5Aj0NKpya 5BrPa11Sx0ATr9qXOjzpp6PXcP15x+B3IQEhUmZa/s39S4E7O8KdksuaLWWtQ+8= =awUv -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, May 06, 2015 at 04:19:17PM -0400, Robert Schweikert wrote:

So far I do not think there has been a big rush to actually build packages from the released SLE sources. Maybe this also says something about the overall "excitement" over this event ;) .

Seriously? It's exactly one week since the announcement - which was really terse and kind of cryptic and didn't even mention _where_ in OBS the sources are. And openSUSE conference fell into that week. BtW, do you have something to support that? Or do you just _assume_ it? Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Onsdag den 6. maj 2015 20:53:10 skrev Michal Kubecek:

I don't think marketing is the problem. The problem is that with the change of approach to Tumbleweed and Factory, current Tumbleweed attracted substantial part of those openSUSE users who focus on new versions and new features. As a result of these changes, 13.2 lost big part of its "added value" and became less attractive.

Richard himself showed about 11.000 Tumbleweed users, and ~150.000 13.2 downloads in the presentation. The presentation even showed growth for 13.2 compared to 13.1.

The way I understand Richard's arguments, he believes one way to regain some of the sense to the releases is to move them more away from the Tumbleweed so that they could target a different group of users, in particular group openSUSE failed to target for long time. And I agree with him.

Which group of users is this? The people running CentOS and Debian Stable today? I.e. a few server users who don't need contemporary applications and hardware support (I'm still not convinced about the SLE base supporting recent consumer desktop hardware, especially not 2-4 years from now). The main complaint about the current openSUSE releases from the "stability crowd", is the lifetime in my opinion, and that would largely adressed by going to a 12 month release cycle, equaling 26 month lifetime (2 releases+2 months). I really doubt too many users will be willing to trade package availability, up-to-date applications and hardware support for the bit of extra stability from the SLE base. Particularly if the difference in lifetime is not huge (26 months vs. "at least 36 months")

...

"The 13.2 release required a large amount of work from a small number of people to make it a success."

will not be resolved just because we pick a different base.

I disagree. People have free will, they won't come just because we need them. They will if we do something to attract them. I believe offering a solution in the area where we have been failing to provide one for years is more likely to attract users and contributors than offering two versions of a distribution that are not too far from each other.

I doubt you can attract packagers to work on this thing. Not Tumbleweed packagers. In my experience even Debian packagers aren't to enthusiastic about working on Debian Stable or backporting stuff to such an old base. And you also have to take into account the less technical contributions of marketing, artwork, translations, testing, writing howtos, supporting people on forums and irc etc. (this group includes me). I just can't see the attraction. As far as I can tell it'll be like Mint/Ubuntu LTS, only more outdated, and with similar or less lifetime or like CentOS, with some more packages available, but with much shorter lifetime. -- 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: SHA1 On 2015-05-09 15:42, Raymond Wooninck wrote:

On Saturday 09 May 2015 14:42:08 Martin Schlander wrote:

In my opinion we are all making assumptions here without actually knowing what is required by the group of users (Future and Current), that is not attracted to the openSUSE Tumbleweed releases.

I can imagine that there might be a group of users, that wants to have a stable release that is support for a certain period, but I wonder like Martin if they would opt-in for a 3-year release cycle.

Not me. I might do it on my server, but not on my desktop machines, unless there is some problem impeding me upgrade.

If SLE12 now would be chosen as the base for the next openSUSE release, then it would mean that we release a new product with "old" packages. Maybe preferred by some users, but I guess that most users still would like to have something newer. Why otherwise to upgrade from 13.2, if you get nothing newer in return.

That's right... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVORecACgkQtTMYHG2NR9XIjgCfepzPswb4bVh0cs5zWDz9MSrp eDkAn0LbnTz2RQshLm0r+M2GAoOkDcFh =WMoF -----END PGP SIGNATURE----- -- 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: SHA1 On 05/09/2015 09:42 AM, Raymond Wooninck wrote:

On Saturday 09 May 2015 14:42:08 Martin Schlander wrote:

...

The main complaint about the current openSUSE releases from the "stability crowd", is the lifetime in my opinion, and that would largely adressed by going to a 12 month release cycle, equaling 26 month lifetime (2 releases+2 months).

In my opinion we are all making assumptions here without actually knowing what is required by the group of users (Future and Current), that is not attracted to the openSUSE Tumbleweed releases.

Well if you consider only users that are not currently on this list and not users of openSUSE I would tend to agree with your statement. However, I think in this thread we have seen statements from 3 distinct groups. From my point of view there is no reason not to believe that each of these groups would not be represented within the group of people not participating in the discussion. - - We have heard from the Tumbleweed users and those that are considering potential use under certain circumstances. - - We have heard from those that like the current snapshot based releases, ~12 months cycle. Primary statements revolve around reasonable stability, not too far behind upstream, reasonably current HW support etc. - - We have heard from those that like longer cycles and more stability. These statements often focus on production use and server deployments. I think each of the voices heard is a representation of the separation of users. We can argue about percentages and how this would divide and we'd probably never reach agreement. But I think we can probably all see these 3 distinct tendencies.

I can imagine that there might be a group of users, that wants to have a stable release that is support for a certain period, but I wonder like Martin if they would opt-in for a 3-year release cycle.

Yes, from those big three categories we can probably come up with an infinite number of further distinction. Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVT03CAAoJEE4FgL32d2UkqpEIAL20+mOaN6p9QLptjFW6Ilm0 1bqZ6hVuzemkpbKA7UzCVq+GkRuD1CBde/0YkHm9nsa1LIQ00+zXz2mUUDdXFzLG oTLnh/hD5u34RQ0ZpQ2ASJPIHwkGGZNFMfAvDfqz3ZcPabGJSjcr6CdQQii6Zkrm hmOnV8IIHbNEQCoJC6Qk875IISo/KR/tsKKUdO0xXND9GOLm1c9ttr9UC958YB+T OHz8hRDAgWi5d/9Qoywp6zjrYJIZbQmpA/UqMA2UZjjFtw4N2YTOWVykhP7bD8qW kqDZmN9qhSg7GCK/huRSCm5DN7Fz9k//2nX/N3yhlosKbXr/9zU6dBV0hnsDlzk= =beqP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 05/09/2015 03:42 PM, Martin Schlander wrote:

Onsdag den 6. maj 2015 20:53:10 skrev Michal Kubecek:

...

I don't think marketing is the problem. The problem is that with the change of approach to Tumbleweed and Factory, current Tumbleweed attracted substantial part of those openSUSE users who focus on new versions and new features. As a result of these changes, 13.2 lost big part of its "added value" and became less attractive. Richard himself showed about 11.000 Tumbleweed users, and ~150.000 13.2 downloads in the presentation. The presentation even showed growth for 13.2 compared to 13.1.

...

The way I understand Richard's arguments, he believes one way to regain some of the sense to the releases is to move them more away from the Tumbleweed so that they could target a different group of users, in particular group openSUSE failed to target for long time. And I agree with him. Which group of users is this? The people running CentOS and Debian Stable today? I.e. a few server users who don't need contemporary applications and hardware support (I'm still not convinced about the SLE base supporting recent consumer desktop hardware, especially not 2-4 years from now).

The main complaint about the current openSUSE releases from the "stability crowd", is the lifetime in my opinion, and that would largely adressed by going to a 12 month release cycle, equaling 26 month lifetime (2 releases+2 months).

I really doubt too many users will be willing to trade package availability, up-to-date applications and hardware support for the bit of extra stability from the SLE base. Particularly if the difference in lifetime is not huge (26 months vs. "at least 36 months")

...

...

"The 13.2 release required a large amount of work from a small number of people to make it a success."

will not be resolved just because we pick a different base. I disagree. People have free will, they won't come just because we need them. They will if we do something to attract them. I believe offering a solution in the area where we have been failing to provide one for years is more likely to attract users and contributors than offering two versions of a distribution that are not too far from each other. I doubt you can attract packagers to work on this thing. Not Tumbleweed packagers. In my experience even Debian packagers aren't to enthusiastic about working on Debian Stable or backporting stuff to such an old base.

And you also have to take into account the less technical contributions of marketing, artwork, translations, testing, writing howtos, supporting people on forums and irc etc. (this group includes me). I just can't see the attraction.

As far as I can tell it'll be like Mint/Ubuntu LTS, only more outdated, and with similar or less lifetime or like CentOS, with some more packages available, but with much shorter lifetime. Excellent points Martin,

I also feel that expanding the gap between Tumbleweed packages and stable release, will make users move away from openSUSE. In the end it has to do with the project's vision: Do we want to be a stable alternative to Debian and CentOS for server usage (as SLE is) or do we want to be something stable but also appealing to the Desktop users, who are willing to upgrade package versions once a year. Hitting both targets with one distribution is a long shot. And if we don't have the resources to maintain 2 distributions (SLE-based and Factory-based), lets chose one closer to our current users and not enter the server market. Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sat, May 9, 2015 at 1:10 PM, Wolfgang Rosenauer wrote:

Hi,

Am 09.05.2015 um 17:56 schrieb Angelos Tzotsos:

...

I also feel that expanding the gap between Tumbleweed packages and stable release, will make users move away from openSUSE.

In the end it has to do with the project's vision: Do we want to be a stable alternative to Debian and CentOS for server usage (as SLE is) or do we want to be something stable but also appealing to the Desktop users, who are willing to upgrade package versions once a year. Hitting both targets with one distribution is a long shot. And if we don't have the resources to maintain 2 distributions (SLE-based and Factory-based), lets chose one closer to our current users and not enter the server market.

In a perfect world we probably want three distributions: Tumbleweed openSUSE as of today/yesterday openSUSE "LTS"

At least I would want this (I could live w/o Tumbleweed actually).

But this is totally out of the scope of we can maintain at the moment. (Actually not that totally because with Evergreen we have such a thing but it suffers from too few contributors.)

Now the question really comes down to "closer to our current users". As far as I can remember we had stats that a _lot_ of people are still on old outdated, unmaintained openSUSE versions.

https://lizards.opensuse.org/wp-content/uploads/2013/08/uuid_month.png From: https://lizards.opensuse.org/2013/08/23/more-on-statistics/ Unfortunately they are a couple years old. And yes they are surprising. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

...

In a perfect world we probably want three distributions: We have the capacity to maintain two distributions 1 Tumbleweed Rolling Distribution 1 openSUSE Stable Distribution

However, we are very limited on the number of people actually working on the Stable distribution, and so I think embrasing the opportunity to use the SLE sources for all their worth will do a great deal of good to get new people involved there, while simultaniously reducing the work required as we'd be benefiting from the work already done by SUSE. As discussed yesterday, if we are using the tools correctly, then we could

On Saturday 09 May 2015 19:50:06 Richard Brown wrote: maintain the two distributions. But that would also mean that in my opinion we need to split the distribution in multiple rings/modules. E.g. We were delivering newer version for the KDE 4 desktop environment by utilizing the power of OBS and created a separate repository that was building for multiple openSUSE releases (KDE:Current). Utilizing this was beneficial for a lot of users, but also for the team itself as that we only needed to maintain a single set of packages. However with this approach we always had to be careful that a newer version could also mean newer version for buildrequirements. Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, May 13, 2015 at 11:14 AM, Johannes Kastl wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 09.05.15 Richard Brown wrote:

...

We have the capacity to maintain two distributions 1 Tumbleweed Rolling Distribution 1 openSUSE Stable Distribution

Some people mentioned Evergreen. Why not think about using the man power going into evergreen (that AFAIK is a user driven group effort) for this LTS release. But make it 'more official'?

Note: I'm not sure what the evergreen group think about this.

Johannes

The "Evergreen group" is 2 or 3 dedicated souls. For userspace they basically watch the security patches coming out for officially maintained releases and backport them if appropriate. For the kernel they have migrated the evergreen release to the closest SLE kernel which is newer than the original evergreen kernel and migrated to it. Greg -- 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: SHA1 On 13.05.15 Wolfgang Rosenauer wrote:

As we are all volunteers and have our own requirements currently bundled in Evergreen we most likely will join forces for creating a different kind of openSUSE _if_ it fulfills our needs. Richard's proposal comes pretty close to mine at least. A lot of details to be sorted out though.

This sounds to me like 'the evergreen maintainers' are not afraid that their baby might be taken away. If the requirements match, that is. Thanks for your answers, guys. Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlVU5K4ACgkQzi3gQ/xETbJxIwCdG/DJqnJRz6woAjB313xOSLWg drAAoIKt12S3hr2ElWjW4ZsiSUlsr/86 =+ZCR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Wolfgang Rosenauer [2015-05-09 19:11]:

Hi,

Am 09.05.2015 um 17:56 schrieb Angelos Tzotsos:

...

I also feel that expanding the gap between Tumbleweed packages and stable release, will make users move away from openSUSE.

In the end it has to do with the project's vision: Do we want to be a stable alternative to Debian and CentOS for server usage (as SLE is) or do we want to be something stable but also appealing to the Desktop users, who are willing to upgrade package versions once a year. Hitting both targets with one distribution is a long shot. And if we don't have the resources to maintain 2 distributions (SLE-based and Factory-based), lets chose one closer to our current users and not enter the server market.

In a perfect world we probably want three distributions: Tumbleweed openSUSE as of today/yesterday openSUSE "LTS"

At least I would want this (I could live w/o Tumbleweed actually).

But this is totally out of the scope of we can maintain at the moment. (Actually not that totally because with Evergreen we have such a thing but it suffers from too few contributors.)

Actually it should be possible if Evergreen were to be based on the SLE sources, in combination with the new SLE backports that should eventually cover the LTS server use case and be less work than today since you wouldn't have to monitor and backport security fixes yourself any more. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 9 May 2015 at 14:42, Martin Schlander wrote:

Richard himself showed about 11.000 Tumbleweed users, and ~150.000 13.2 downloads in the presentation. The presentation even showed growth for 13.2 compared to 13.1.

Users, yes. But the graph for 'contributors to the Regular Release' is a very different story. and its the desire and momentum of contributors actually contributing to getting a Regular Release out that we need to consider when we talk about doing one.

Which group of users is this? The people running CentOS and Debian Stable today? I.e. a few server users who don't need contemporary applications and hardware support (I'm still not convinced about the SLE base supporting recent consumer desktop hardware, especially not 2-4 years from now).

The main complaint about the current openSUSE releases from the "stability crowd", is the lifetime in my opinion, and that would largely adressed by going to a 12 month release cycle, equaling 26 month lifetime (2 releases+2 months).

I really doubt too many users will be willing to trade package availability, up-to-date applications and hardware support for the bit of extra stability from the SLE base. Particularly if the difference in lifetime is not huge (26 months vs. "at least 36 months")

The majority of our user base - look at Alberto's presentation from oSC 13 that shows the actual user numbers of our repositories, and how lots of people keep on older versions for a lot longer than we say they should https://www.youtube.com/watch?v=NwfohZ8RBd8

I doubt you can attract packagers to work on this thing. Not Tumbleweed packagers. In my experience even Debian packagers aren't to enthusiastic about working on Debian Stable or backporting stuff to such an old base.

I think you're wrong here.. I was having some very interesting conversations with the KDE team last night, and they were coming up with all kind of ideas of doing very exciting things ontop of this. We have the tools, talent, and expetise to do things that no other distribution can even consider - openSUSE-based-on-SLE with official 'add-on modules' for Desktops for example (eg. KDE:Current, or GNOME:Stable)? So the desktops can move at a pace that suits the community, while the core doesn't change? These are exciting ideas which I think might work to address your doubts and turn this idea for a Regular Release into something exceptional - We need to avoid falling into the trap of thinking of this 'like a Debian' or 'like a CentOS' - We're openSUSE, let's build something which only we can do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, May 11, 2015 at 2:10 AM, Stefan Schäfer wrote:

Am 09.05.2015 um 19:45 schrieb Richard Brown:

...

We're openSUSE, let's build something which only we can do.

This should be a slogan for openSUSE T-Shirts. ;-)

I'm totally onboard with that. Actually, I'd love to see some openSUSE polos that I could purchase and then wear to work.

Stefan

-- www.invis-server.org

Stefan Schäfer Ludwigstr. 1-3 63679 Schotten

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

-- Sincerely, Bob Martens Webmaster/Technician Martin Luther College http://mlc-wels.edu -- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Per Jessen wrote:

Robert Martens wrote:

...

On Mon, May 11, 2015 at 2:10 AM, Stefan Schäfer wrote:

...

Am 09.05.2015 um 19:45 schrieb Richard Brown:

...

We're openSUSE, let's build something which only we can do.

This should be a slogan for openSUSE T-Shirts. ;-)

I'm totally onboard with that. Actually, I'd love to see some openSUSE polos that I could purchase and then wear to work.

I saw these guys mentioned recently:

https://www.hellotux.com/opensuse

Plenty of them: http://shop.opensuse.org/ http://www.amazon.de/Fruit-Loom-Polo-Shirt-openSUSE-Schriftzug/dp/B003FYCAL0 http://www.linux-onlineshop.de/Fanartikel/Shirts-/-Kleidung/Polo-Shirts/Dist... -- Per Jessen, Zürich (19.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- 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: SHA1 On 06.05.15 Michal Kubecek wrote:

I don't think marketing is the problem.

Communicating the openSUSE way to the public surely is.

The problem is that with the change of approach to Tumbleweed and Factory, current Tumbleweed attracted substantial part of those openSUSE users who focus on new versions and new features. As a result of these changes, 13.2 lost big part of its "added value" and became less attractive. The way I understand Richard's arguments, he believes one way to regain some of the sense to the releases is to move them more away from the Tumbleweed so that they could target a different group of users, in particular group openSUSE failed to target for long time. And I agree with him.

As an end user, running openSUSE Tumbleweed on my work laptop and 'fool around' machines and running 13.1 in >10 VMs all over the place I agree. I would suggest the following approach for the future: - ---------- Citation ----------- Tumbleweed is for people with new laptops. Drivers have been mentioned . Releases are for long running machines, servers, etc. - ---------- Citation ----------- If I can run my servers on openSUSE for more than the lifetime releases had up til now, I would get rid of having to upgrade 'frequently'. And VMs and servers rarely need the latest software (drivers might be an issue with new servers and new hardware).

It would be even nicer if we could do three distributions: Tumbleweed, something similar to openSUSE <= 13.1 and some "LTS" version (possibly SLE based). But I'm afraid we don't have resources to do all three and there is no easy way to change that fact in short timeframe.

I would rather pick two flavors and do them well. Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlVTpbYACgkQzi3gQ/xETbK/uQCeOiWRskDXIEpfx12TaTFME5sx IX4An1Soce+CTwDHJ8WsgxdZd92PAhNy =YL1I -----END PGP SIGNATURE----- -- 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 2015-05-14 08:34, Stefan Schäfer wrote:

Am 13.05.2015 um 21:27 schrieb Johannes Kastl:

...

...

...

The problem is that with the change of approach to Tumbleweed and Factory, current Tumbleweed attracted substantial part of those openSUSE users who focus on new versions and new features. As a result of these changes, 13.2 lost big part of its "added value" and became less attractive. The way I understand Richard's arguments, he believes one way to regain some of the sense to the releases is to move them more away from the Tumbleweed so that they could target a different group of users, in particular group openSUSE failed to target for long time. And I agree with him. As an end user, running openSUSE Tumbleweed on my work laptop and 'fool around' machines and running 13.1 in >10 VMs all over the place I agree.

I would suggest the following approach for the future:

- ---------- Citation ----------- Tumbleweed is for people with new laptops. Drivers have been mentioned .

Releases are for long running machines, servers, etc. - ---------- Citation -----------

If I can run my servers on openSUSE for more than the lifetime releases had up til now, I would get rid of having to upgrade 'frequently'. And VMs and servers rarely need the latest software (drivers might be an issue with new servers and new hardware).

100% agreement!

You forget the middle ground. Plain desktop/laptop users, wanting reasonably recent software, just not wanting to work the installation or upgrade every some months. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVZQKoACgkQja8UbcUWM1y2tQD+IN+XR54kutp+eQOn2TUyVK7D G+AOUBfQevKBt11a9QcBAIq9Lc7s8ukKsuJOLrTHGjmpNLVtbXyPQtLm6wu7p9ld =4Q8U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On Thu, Apr 30, 2015 at 10:30:23AM +0200, Marcus Meissner wrote:

On Thu, Apr 30, 2015 at 10:18:14AM +0200, Torsten Gruner wrote: [ 8< ]

...

Another solution might be to mark the affected packageswith this kind of changes. And each packet has to be assessed whether a jump to the next version without consequence for the function. Can several versions are skipped? And zypper has to handle this. This is a nice feature but a dream only.

What do you mean with affected packages?

The kernel for example. At some point we had kernel-default-3.19.4-1.1.x86_64 and that got replaced by kernel-default-3.19.4-1.2.x86_64 Both make use of /boot/vmlinuz-3.19.4-1-default resulting in a file conflict.

We try to push out only "stable" and working tumbleweed snapshots and that seems to be working quite well already.

On one of my real systems this worked quite well - cause I power it on less often. But with my daily updated workstation I had trouble several times. I still have two rdsosreport.txt files stored. As it works 3 of 4 times and I don't see a pattern - sometimes booting an older kernel and calling dracut for the failing one help but sometimes I had to make use of a rescue system - and have not reported it to bugzilla yet.

My Laptop is running Tumbleweed and I have so far not have had a single troublesome status.

In the current state Tumbleweed isn't able to pass the relatives test yet. Even getting them using openSUSE 13.2 with a KDM which sets a non KDE session type with one of the recent KDE 13.2 updates is a no go for such users. All they intend more or less is to start a web browser and a text processor. And all this is for me a good reason to have regular openSUSE releases. Once every 12 months if fine. But hey, maybe the openSUSE conference will even bring a much better news to us. :) Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29/04/15 19:41, Michal Kubecek wrote:

On Wed, Apr 29, 2015 at 02:54:30PM -0300, Cristian Rodríguez wrote:

...

Neither is every single software product out there.. ;-) Please make your case on what's the exact problem with having only rolling releases.

For me, the main reason is the fact that upgrades necessarily cause various kinds of problems from time to time. It's not only bugs and regressions but also intentional changes in program behaviour, config file syntax or semantics etc. It's acceptable for me to do a distribution upgrade once a year or two (less often on a server) when I reserve enough time to resolve these issues and I expect things to be broken temporarily. Having such issues continuously hitting me at random times in a "rolling upgrades" model is not acceptable for me.

That's why I'm not using Tumbleweed on any of my machines and I do not intend to.

Michal Kubeček

I considered Tumbleweed, but decided against it based on the advice here: https://en.opensuse.org/Portal:Tumbleweed I use the NVidia proprietary graphics drivers to control my twin screen display. When I read the following... "When you should keep staying at stable release At this point there is no guarantee to have all additional modules available in the stable release like for Vmware or Virtualbox. And while the Packman Tumbleweed Essential repository attempts to deliver them there is no guarantee they will always succeed due to the incompatibilities with the quickly advancing Linux Kernel. The problems with proprietary Graphics drivers are similar and there is no guarantee they will work tomorrow, even if they do today. If you don't know how to compile your own additional kernel modules and you don't wish to learn or keep a very close eye on what is being updated, please don't use Tumbleweed." and "Special Concerns Third Party Drivers If you have 3rd party kernel modules it is STRONGLY suggested that you not use Tumbleweed. Seriously, it's not worth the pain and extra work, unless you _really_ want to do it. And if you do do it, then again, you are on your own, sorry." ...I accept the advice and stick with the stable releases. And even that is not without the occasional problem. :-( Bob - -- Bob Williams System: Linux 3.16.7-7-desktop Distro: openSUSE 13.2 (x86_64) with KDE Development Platform: 4.14.3 Uptime: 06:00am up 7:55, 3 users, load average: 0.16, 0.05, 0.06 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVB898ACgkQ0Sr7eZJrmU5dkACfaRXeebTAAauQiC3PxEf4DgAN xLoAnjP80g6gOeMbPkw7LdG9eRmMomfQ =MHte -----END PGP SIGNATURE----- -- 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: SHA1 On 04/30/2015 05:27 AM, blue hut wrote:

On 30.04.2015 11:20, Bob Williams wrote: > I use the NVidia proprietary graphics drivers to control my twin

...

screen display. When I read the following...

Quick question about this: I have a Macbook with an intel and nvidia graphics card. I used the nouveau driver and nvidia card for some time. But my laptop got really hot. So recently I blacklisted the noveau driver. And only use intel card.

But then I realized: multiple monitor doesn't work with it!

Cant say for the macbook but nouveau definitely supports multiple monitors, you have to configure it using the DE tools (eg. System Settings in KDE). - -- Regards, Uzair Shamim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVQkMjAAoJEM66EOTZRH6+yLYP/iQODR+sEh6i5abkPPP9pWze t2mYp6thXxhf58IsXPSgQNm45XPyaI4P9agOfWNuydKG3poImRLiph1WiGAaxHKj jf2A1h48n3ltVroOd1TarwJeteBrL+2oerNsACD697MkLLdYmR8/XPNO7dAOyMDb BX9tWyGJHIGJ/EleOkj6l82tsnvkrj5Xwchr1Zj1zYbyhIkfk6PwuVBleNRadWTz VCqCe6HXAOTWtoG6gbVajr3A1Rgofyh7mZrVhB7yRPtU6v+GoUyGB6XOSYTCAm1L L3IfIDvIIlsdwCy8pFUuzwU6VQybnamhfJZcZFHcb3C8Qbno48RPIgpQTBWU49Xk vBlVkViX+DBkDg+0lYuR3oxh1CiXG70O938SSBQ7rDtpbuZPIbcXTZHIyDR+3YmI QWAyNp6uPlp5SnmMzyZOPYMQf+qZTPeYdlc6R8oGc7NiJDbdJgm0oqVgskMmFAe/ Nkw+PNObs807olfBxaNmzMAaHY9A1VDWC8oF1+GhvERFC+8SQQ4odG3rMkaraUsx 20yHHiWrb7kWdYGqJFNdXFWmUgAEdjDXFa4SX/kWSim1hoGIPav7y4ll2Jrv9lub 9ikGr+0qDoj5QogeMwVDc3U/CLQ4VJ6Fgbd1ifqWfR4y/NscEbF57p8aIOT21OXy zzFDnIeNpzb5KyLcGWgz =JsAL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org