-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-01 12:07, jdd wrote:

After the Richard talk at OSC,

There is still no video of the presentation. https://events.opensuse.org/conference/osc15/proposal/610 Nor here: http://bambuser.com/v/5475910

In fact it may not be usefull to have three kind of distros, if Tumbleweed is stable enough *and* can cope with proprietary video drivers and Virtualbox drivers (is that kmp?), because it's the only reason one needs really the present openSUSE version

There are many more reasons. But I don't see Tumbleweed ever coping with proprietary blubs: moving target. The proprietary blubs always lag behind by several months. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVDVi0ACgkQja8UbcUWM1x6pAD7BAaIXpFNAkNAqQZKAKevTtcp MAWcASJ3EjlDyADD0tkA/iEdJl8xOfC+Ys0EXfrgw3Sh1JqJwnCvmODlWaQKRT8n =JhEQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 01.05.2015 um 12:07 schrieb jdd:

After the Richard talk at OSC, the status of openSUSE stays unclear, that's normal it have to be discussed, but I see it like this:

* Tumbleweed, the rolling release will the distribution for advanced users * openSUSE? * I new variant (name?) will be more stable, very long time support (at least 3 years), yearly release?

In fact it may not be usefull to have three kind of distros, if Tumbleweed is stable enough *and* can cope with proprietary video drivers and Virtualbox drivers (is that kmp?), because it's the only reason one needs really the present openSUSE version

Actually I would see * Tumbleweed (hopefully a bit more stable and usable with regard to 3rd party integration support (nvidia, virtualbox etc)) * openSUSE $VERSION could/should be based on the SLE code but have - replaced/updated (Gnome and whatever we need newer) and - added (KDE and whatever important packages/desktops are missing in SLES) components Now some questions for details coming up: - do we want the SLES codebase to be installable on its own and have the replaced and additional components optional in additional repos? - leading to two update/maintenance streams for the overlap - Or will this openSUSE dist replace things and create only one repository for that? With the latter I see the "problem" that it'll be very hard to come to a conclusion in the community what to replace/override. This decision will also be hard for the former though but then the user still can decide if he wants to follow the openSUSE fancy stuff or the more ?more? stable SLES core by using an overlay repository. Given that we already have these kind of overlay repos in OBS (KDE, Gnome, etc) having a relatively small set of packages replacing/updating the SLES part but probably focus more on additional ones to compensate the big difference between amount of openSUSE and SLES packages could be a way forward. Just throwing in a few thoughts, Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 1 May 2015 at 12:32, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-05-01 12:07, jdd wrote:

...

After the Richard talk at OSC,

There is still no video of the presentation. https://events.opensuse.org/conference/osc15/proposal/610

Nor here: http://bambuser.com/v/5475910

It was live streamed and recorded - the recording will be posted on YouTube tonight (insufficient bandwidth at the venue for livestreaming and uploading to YouTube) I'll make sure the video gets posted here as soon as it can

...

In fact it may not be usefull to have three kind of distros, if Tumbleweed is stable enough *and* can cope with proprietary video drivers and Virtualbox drivers (is that kmp?), because it's the only reason one needs really the present openSUSE version

There are many more reasons. But I don't see Tumbleweed ever coping with proprietary blubs: moving target. The proprietary blubs always lag behind by several months.

Sad but true, but I also think people would do well to re-evaluate whether they really need the proprietary blobs - the open source drivers are getting better, and are a good choice for many people now. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 01.05.2015 um 16:06 schrieb Richard Brown:

Is it so hard? Those who do, decide - If the GNOME team want to put a new GNOME on this, they can do that.. same for KDE..or any other stack..is there another way we decide anything else?

If just it would be so easy. We had GNOME versions requiring bluez versions that broke KDE and KDE versions requiring cmake versions that broke libsolv. So I would draw a line somewhere - let's say the ~1000 packages of ring0 and ring1 are taken 1:1 from SLE and whoever needs a newer package version in that set needs to make sure it's parallel installable and does not break anything else. The rest on top is more free to change. 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-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Fri, May 1, 2015 at 10:51 AM, Robert Martens wrote:

I think the two-distro options feels like the best one at the moment. Would the Essence-based openSUSE release also subsume the Evergreen team as well? Could it? Am I really behind the curve and Evergreen is already gone?

Sincerely, Bob Martens

Evergreen is alive and well, but between major activities: https://en.opensuse.org/openSUSE:Evergreen#Supported_distributions 13.1 has been designated an Evergreen release was originally scheduled to enter Evergreen support mode May 2015 (ie. now). But it is still in official support, so there is little (or nothing) for the Evergreen team (of 2 or 3 people) to do at present. Given the 13.1 official support period has been extended by at least 6 months I don't know what the Evergreen support plan is for 13.1 at this point. Greg -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Richard, thanks to that hot topic, we chose this to be the first video to hit youtube: https://youtu.be/BH99TSrfvq0 All, the playlist, where all the osc15 contents is uploaded is this: https://www.youtube.com/playlist?list=PL_AMhvchzBaeV36wYqnKb7xWAN0zfDfjz cheers, JW- On Fri, May 1, 2015 at 8:39 PM, Michal Kubecek wrote:

On Fri, May 01, 2015 at 09:51:52AM -0500, Robert Martens wrote:

...

I think the two-distro options feels like the best one at the moment. Would the Essence-based openSUSE release also subsume the Evergreen team as well? Could it? Am I really behind the curve and Evergreen is already gone?

I don't think so. IMHO even with the SLE Core, I don't think longer (3 and more years) support of every openSUSE release (released once a year) is feasible. After all, even Richard in his talk (I have only seen the slides so far) mentions numbers like ~1000 packages in Core (even if the key ones) and ~6000 in total. We simply do not have resources for that.

So either the intervals between releases will be longer or not every release can get full length of support. Either way, what's new is that the basic set of packages (Core) can get much better level of support even for releases with shorter support length.

(Of course, this is only the way I see it, I may still be pleasantly surprised for once.)

Michal Kubeček

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

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

Hi, Am 01.05.2015 um 18:26 schrieb Greg Freemyer:

On Fri, May 1, 2015 at 10:51 AM, Robert Martens wrote:

...

I think the two-distro options feels like the best one at the moment. Would the Essence-based openSUSE release also subsume the Evergreen team as well? Could it? Am I really behind the curve and Evergreen is already gone?

Evergreen is alive and well, but between major activities:

https://en.opensuse.org/openSUSE:Evergreen#Supported_distributions

13.1 has been designated an Evergreen release was originally scheduled to enter Evergreen support mode May 2015 (ie. now).

But it is still in official support, so there is little (or nothing) for the Evergreen team (of 2 or 3 people) to do at present.

Given the 13.1 official support period has been extended by at least 6 months I don't know what the Evergreen support plan is for 13.1 at this point.

Thanks for the explanation Greg. So indeed the plan currently is unchanged from Evergreen perspective. But then again, the outcome of all this discussion and new movement will probably have a direct impact on openSUSE 13.1 Evergreen. Because in case openSUSE really moves to a longer maintained release with a SLES base the extra Evergreen project might not be required anymore. So let's imagine we would decide (and get delivered) an openSUSE 13.3 with a SLES base which is maintained by SUSE and the openSUSE community for 3 years (at least) it could happen that next Evergreen would be maintained for a shorter time with a recommendation to update to 13.3 and go from there. So basically if the goals of Evergreen are finally delivered by openSUSE next it's probably not required anymore. (Or said differently: Evergreen project and openSUSE could directly join forces with SUSE to deliver a distro which would count as LTS.) But the Evergreen discussion can really start only after the openSUSE vision is clear and for the time being in case required Evergreen will eventually start with 13.1 maintenance. Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 01.05.2015 um 23:32 schrieb Wolfgang Rosenauer:

If the project finally agrees to have something more stable and longer maintained and the approach of service packs every 12 months is

And this is the key point. We have to decide for ourselves, what we want to achieve with openSUSE releases. And if we go there, we have to live with the consequences - i.e. accepting the patch madness SLE packages can be. 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-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 2 May 2015 at 01:43, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-05-01 21:22, Jürgen Weigert wrote:

...

Richard, thanks to that hot topic, we chose this to be the first video to hit youtube:

https://youtu.be/BH99TSrfvq0

Thanks for posting the link. The official page doesn't have it:

https://events.opensuse.org/conference/osc15/proposal/610

I think you'll find it does now..

- -- Cheers / Saludos,

Carlos E. R.

(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlVED40ACgkQja8UbcUWM1wvGAD/SsIJBzCkl90OsUNQkWQT3Xvx 9E66HhZ8bqPqThUPRBsA/3cfVZDHOjSwpJuXt5qr30svDh/Fh/5N4VVD/0LsY1y3 =Dy8L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

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

On Saturday 2015-05-02 02:01, Carlos E. R. wrote:

I'm watching it now. Just paused it to mention that the left audio channel is almost mute.

Given that most microphones just produce one channel of audio, that is not very surprising :) But indeed, it ought to have been center-balanced when muxed into the stereo stream, which did not quite occur. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-01 15:57, Richard Brown wrote:

On 1 May 2015 at 12:32, Carlos E. R. <> wrote:

I'll make sure the video gets posted here as soon as it can

I just watched it. I was about to post when my laptop crashed. Well, the battery run out. It actually asked for my root password to try hibernate, but I did not notice why and refused. It is a known bug of XFCE, it requests for root password to hibernate, even on emergencies, and it does so behind the screensaver, so you do not see the prompt. Known and reported bug. Not subject for here, though. Well, what was I saying... ah, that I just watched the video. Interesting... I'm still digesting it. I'm not averted to the idea, in principle... I have doubts, though.

...

There are many more reasons. But I don't see Tumbleweed ever coping with proprietary blubs: moving target. The proprietary blubs always lag behind by several months.

Sad but true, but I also think people would do well to re-evaluate whether they really need the proprietary blobs - the open source drivers are getting better, and are a good choice for many people now.

For many, true, but not for all. If it is about video drivers, the open source drivers will always lag in features compared to the closed source drivers, and these are behind the Windows counterparts (I'm thinking of Nvidia). The hardware companies will see to it that the open drivers have a hard time and never fully catch up. In many cases, the open source driver suffices, but not always. And then there are other proprietary blobs with no alternative at all. The obvious case is virtualbox or vmware, but there are more. Some printers, for instance. Or proprietary suites. They can target SLES, but not Tumbleweed. A stable openSUSE release has a chance. And after your proposal, chances are better. By the way, talking of stable... Stability is not only about not crashing. It is also not having to "touch" the installation often: just install once, then use the computer for many months, with patches, yes, but without having to configure again services, reading manuals because something changed (with the new version), etc. Which is kind of the meaning of "static". We want stability in order to work with the computer, not for the computer ;-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVEJgYACgkQja8UbcUWM1y1QAD/ekCVwREtz2ve+s0PhVaknHV0 6AQA+L2UAjDOkDKlcJgA/iurQ6n6RpT98DzXDn4fYXo6Ms356rNb5RbQWIAFcwca =SIpK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-02 03:29, Michal Kubecek wrote:

On Sat, May 02, 2015 at 03:19:02AM +0200, Carlos E. R. wrote:

...

And then there are other proprietary blobs with no alternative at all. The obvious case is virtualbox or vmware, but there are more.

Not sure which modules you mean here. Both host and guest VMware modules are provided with their source and this source is used to build the modules if you don't have one of the kernels for which pre-built modules are provided (I never had). Actually, some of their modules that used to be out-of-tree have been merged into mainline kernel (vsock, vmw_vmci).

Sometimes the kernel changes "too much" and the vmware module refuses to build (during install of vmware, it builds things automatically). With luck, some one publishes a patch that you have to apply manually, and it works. Then someone writes a script. And, maybe six months later, vmware publishes a new version that handles the kernel change properly. This has happened several times in the past. It even happens with stable openSUSE releases, which is a reason to not install it till after a few months... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVEMT4ACgkQja8UbcUWM1zgeQD/cGxoDhgM2kY0WLrYCP6Eyufx +7Grx0FVf/oK72ZG4n0A/3fvUkmhAcZMoHSBQS1fYwgZbEJwPXHCbf+pawL92H/A =1A0Y -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sat, May 02, 2015 at 04:06:54AM +0200, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-05-02 03:29, Michal Kubecek wrote:

...

On Sat, May 02, 2015 at 03:19:02AM +0200, Carlos E. R. wrote:

...

And then there are other proprietary blobs with no alternative at all. The obvious case is virtualbox or vmware, but there are more.

Not sure which modules you mean here. Both host and guest VMware modules are provided with their source and this source is used to build the modules if you don't have one of the kernels for which pre-built modules are provided (I never had). Actually, some of their modules that used to be out-of-tree have been merged into mainline kernel (vsock, vmw_vmci).

Sometimes the kernel changes "too much" and the vmware module refuses to build (during install of vmware, it builds things automatically). With luck, some one publishes a patch that you have to apply manually, and it works. Then someone writes a script. And, maybe six months later, vmware publishes a new version that handles the kernel change properly.

This has happened several times in the past. It even happens with stable openSUSE releases, which is a reason to not install it till after a few months...

IMHO this exactly shows why it's incorrect and unfair to call these modules "proprietary blobs". When this (kernel API change affecting the build) happens, I'm usually able to fix the module myself and, actually, I almost never really have to as a patch is already on VMware forums. Sure, most users can't do that themselves but the sources are available and it's possible to fix the problem or find someone who does. If the modules really were "proprietary blobs", I would have no other choice than waiting for VMware to release a module, no matter what my knowledge or coding skill are. Even worse, it would be the same even if there were no API change, I would have to rely on the vendor whenever ABI changes. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le 01/05/2015 23:26, Wolfgang Rosenauer a écrit :

But the Evergreen discussion can really start only after the openSUSE vision is clear and for the time being in case required Evergreen will eventually start with 13.1 maintenance. Wolfgang yes.

What also could be done is working on a better transition between two LTS versions. I don't know if such thing is already on the go with openQA (for example): is it possible to test upgrade? I an't help fixing bugs, but I could help documenting upgrade from one LTS to the next one jdd -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 05/01/2015 09:06 PM, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2015-05-02 03:29, Michal Kubecek wrote:

...

On Sat, May 02, 2015 at 03:19:02AM +0200, Carlos E. R. wrote:

...

And then there are other proprietary blobs with no alternative at all. The obvious case is virtualbox or vmware, but there are more.

Not sure which modules you mean here. Both host and guest VMware modules are provided with their source and this source is used to build the modules if you don't have one of the kernels for which pre-built modules are provided (I never had). Actually, some of their modules that used to be out-of-tree have been merged into mainline kernel (vsock, vmw_vmci).

Sometimes the kernel changes "too much" and the vmware module refuses to build (during install of vmware, it builds things automatically). With luck, some one publishes a patch that you have to apply manually, and it works. Then someone writes a script. And, maybe six months later, vmware publishes a new version that handles the kernel change properly.

This has happened several times in the past. It even happens with stable openSUSE releases, which is a reason to not install it till after a few months...

When a kernel API changes, vmware is a lot slower than virtualbox to implement those changes. When kernel 4.1-rc1 was released and symbol IRQF_DISABLED was no longer defined, VB had a fix available in days. I had already found and fixed the problem, but I did not bother to submit it to Oracle as I knew they would have already had the patch in testing. Larry -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le 02/05/2015 18:37, Larry Finger a écrit :

When a kernel API changes, vmware is a lot slower than virtualbox to implement those changes. When kernel 4.1-rc1 was released and symbol IRQF_DISABLED was no longer defined, VB had a fix available in days. I had already found and fixed the problem, but I did not bother to submit it to Oracle as I knew they would have already had the patch in testing.

Larry

can you or somebody else make sure that virtualbox runs on tumbleweed? I don't care of recompiling the module, but I want virtualbox :-) thanks jdd -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le 02/05/2015 21:15, Carlos E. R. a écrit :

No, the point is upgrading 11.4 (on evergreen) to 13.1 (will be on evergreen).

yes, mostly

This was not tested, and the procedure actually refused; I had to force it to go ahead, and it worked perfectly. It refused simply because 11.4 has no /etc/os-release file.

they may be more than that. I don't see any use of evergreen on desktop (but may be it's just me), but a strong one on servers, because servers do not need usually very new applications, and servers are often remote and so very picky to update -you can't insert a dvd in the reader :-). But I may see interest in detailed upgrade, including what have changed from last time and is interesting to adapt? I did a bit of this in my page http://dodin.info/wiki/pmwiki.php?n=Doc.OpenSUSE-small-ThirdEdition but could do something more in depth if needed jdd -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-02 21:22, jdd wrote:

Le 02/05/2015 21:15, Carlos E. R. a écrit :

I don't see any use of evergreen on desktop (but may be it's just me),

Yes :-) I used 11.4 on both my desktop and laptop. I delayed mostly because systemd was still flaky and needed it to stabilize, and me learn enough about it. And if you maintain a room of desktops for office, it makes sense to not update often, if the software you need works. Maybe upgrade some applications. Notice that one use of Evergreen is not to use it for three years, but for two. 18 months is too short, specially considering that you may need a month or more after release for certain bugs to be solved before you upgrade. So you stay on Evergreen for some months till you can upgrade.

but could do something more in depth if needed

I wrote most (all?) of the wiki page on offline upgrade. Needs work, but what it says still holds. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVFLOsACgkQja8UbcUWM1wHnwD/WhhBiNrBr0g15ezMW3243NFS oMHXg0vkudMQC25jwzgA/Rc05qBdFYvkujd8S06llo9sA/XXegOZp89KnH+EHsQD =zyNr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

01.05.2015 13:07, jdd пишет:

After the Richard talk at OSC, the status of openSUSE stays unclear, that's normal it have to be discussed, but I see it like this:

* Tumbleweed, the rolling release will the distribution for advanced users * openSUSE? * I new variant (name?) will be more stable, very long time support (at least 3 years), yearly release?

In fact it may not be usefull to have three kind of distros, if Tumbleweed is stable enough *and* can cope with proprietary video drivers and Virtualbox drivers (is that kmp?), because it's the only reason one needs really the present openSUSE version

just my understanding

jdd

Hi, having read amount of mail on the topic, I would like to say the following: I like idea to have Rolling-Release + Shared-with-SLE-core on x86. But, basically it won't work on armv7 boards. I have been trying to run openSUSE on BeagleBone Black for one year or so and found that tuning/fixing the kernel is the largest part of work. I have to say that openSUSE Kernel people are kind and always accept my patches/configs even to released kernels. When I started, BeagleBone Black did not even boot on openSUSE 13.1, and then dozen of patches were applied for 13.1-branch after 13.1 release to make it bootable. The almost same story was with 13.2. I don't think that this approach will be acceptable for kernel shared with SLE (http://kernel.opensuse.org/cgit/kernel-source/tree/?h=SLE12-SP1 doesn't even have armv7 configs). And looking back into past, I would not say that it is easy to backport all BeagleBone related stuff from 4.1 into 3.12. And after five years or so, when SLES 13(?) will be released with new kernel - BeagleBone board will be most likely ruined and obsoleted and nobody will need it support. So, the point here, that for Ports (armv6 armv7) we just won't have Not-Rolling Release. At the same time Rolling-Release part is being developed way too fast for me and other ARM people, in my opinion. Because something always broken in ARM part of Linux kernel (once, updating from 3.16.2 to 3.16.3 just broke booting on BBB ;) and the time is required to understand what is broken and to send patches to upstream. I would not say that *-rc period is usually sufficient to do so. And as a consequence, tumbleweed kernel fails to boot on different boards with major updates (i.e. 3.17 -> 3.18) from time to time. You may think of people with RPi and all this stuff as crazy hobbyists blinking their leds, but I am personally use one BBB in production as inexpensive industrial automation solution and I don't want the tumbleweed update eventually bricks my system due to bug in kernel which we could not fix in time. So at this point, neither rolling-release nor stable-core-release are suitable for current openSUSE:Ports (armv6 armv7) (IMO) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

03.05.2015 14:51, Michal Hrusecky пишет:

Matwey V. Kornilov - 11:36 3.05.15 wrote:

...

01.05.2015 13:07, jdd пишет:

...

After the Richard talk at OSC, the status of openSUSE stays unclear, that's normal it have to be discussed, but I see it like this:

* Tumbleweed, the rolling release will the distribution for advanced users * openSUSE? * I new variant (name?) will be more stable, very long time support (at least 3 years), yearly release?

In fact it may not be usefull to have three kind of distros, if Tumbleweed is stable enough *and* can cope with proprietary video drivers and Virtualbox drivers (is that kmp?), because it's the only reason one needs really the present openSUSE version

just my understanding

jdd

Hi, having read amount of mail on the topic, I would like to say the following:

I like idea to have Rolling-Release + Shared-with-SLE-core on x86. But, basically it won't work on armv7 boards. I have been trying to run openSUSE on BeagleBone Black for one year or so and found that tuning/fixing the kernel is the largest part of work.

I found it to be so big part, that I prefer to use custom kernel then the distribution one. And it should be no big deal to keep different kernel for ARM - there are different images anyway.

The rootfs and packages work, just kernel needs to be special in some cases. But as more and more is getting upstream and mainstream I think that over the time it will be easier and easier to integrate everything needed in Tumbleweed. For regular release, I would say using a different kernel for ARM might be an option.

Downstream kernels also have drawbacks like possible incompatibility in user-space, broken API, insecurity, etc. So, for me TI AM33xx platform is okay in upstream kernel, most of problems were not related to hardware or lack of support but to bad coding style in kernel itself. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

2015-05-04 15:56 GMT-03:00 oldcpu :

From the view of one of the openSUSE forum moderators (and the other moderators may have a different view, as this is my private view wrt giving support) I am not particularly keen on seeing a kernel that is too old with openSUSE. Again , this comes from a forum support viewpoint.

Currently , I believe the openSUSE packagers have done a super job with their kernel management, ensuring openSUSE gets a new fairly recent and stable kernel every 9-months or so (timed to the new release).

This 'not too old' kernel has a significant advantage from a support point of view, which means new hardware support (that is not too ancient) is constantly fed into openSUSE. One does not often need to go to tumbleweed (to get a possibly less tested openSUSE kernel version) to obtain more recent hardware support from a newer kernel.

ie if SLE has an old kernel, I would be concerned that the hardware support for openSUSE would suffer. Reviewers/new-users installing openSUSE for the first time (who are not aware of Tumbleweed) could stumble and have problems here.

Would applying a Tumbleweed kernel be the only way to address such an older kernel concern ?

Lee

Hi, No, probably just add the Kernel:Stable to that install, just like nowadays. Regards, Luiz -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tuesday 2015-05-05 00:35, oldcpu wrote:

On 05/04/2015 11:52 PM, Luiz Fernando Ranghetti wrote:

...

2015-05-04 15:56 GMT-03:00 oldcpu :

...

From the view of one of the openSUSE forum moderators (and the other moderators may have a different view, as this is my private view wrt giving support) I am not particularly keen on seeing a kernel that is too old with openSUSE. Again , this comes from a forum support viewpoint. .... Would applying a Tumbleweed kernel be the only way to address such an older kernel concern ?

No, probably just add the Kernel:Stable to that install, just like nowadays.

OK. Good to know of the alternative.

Wat "alternative". If everybody has to add K:S to /etc/zypp/repos.d, we can just directly have the fresh kernels published through openSUSE:Update instead. And that's not even touching the question of support, because support can be equally present or absent no matter the package source location. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Monday 04 of May 2015 20:56:17 oldcpu wrote:

This 'not too old' kernel has a significant advantage from a support point of view, which means new hardware support

No, it does not. "Support point of view" is something completely different: how well are we able to support the kernel packages. And this would be actually one of the reasons why consider SLE (or SLE based) kernel even if it may be seen "too old" by some. Michal Kubeček -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-05 09:34, Michal Kubecek wrote:

On Monday 04 of May 2015 20:56:17 oldcpu wrote:

...

This 'not too old' kernel has a significant advantage from a support point of view, which means new hardware support

No, it does not. "Support point of view" is something completely different: how well are we able to support the kernel packages. And this would be actually one of the reasons why consider SLE (or SLE based) kernel even if it may be seen "too old" by some.

He refers to support as in users helping other users to diagnose and solve their problems, via email or web forum. And for the record, most of this happens in the forums, not in the mail lists. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVIwKIACgkQja8UbcUWM1x0VAEAlJHQyyi8CNsbn62sRd2Qg5vl auO/Qw6ItJNY8HHto6wBAJI8q9mvqSwjJyKEobjEEDU8YhbNvddVO+ddQfDqZk3d =oQ8O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tue, 05 May 2015 09:34:11 +0200, Michal Kubecek wrote:

No, it does not. "Support point of view" is something completely different: how well are we able to support the kernel packages. And this would be actually one of the reasons why consider SLE (or SLE based) kernel even if it may be seen "too old" by some.

Well, yes and no. We get users who often ask about how to get the latest kernel on their build because they want new features (not just backported fixes). The kernel is probably going to be the biggest thing to sort out - making sure that we're meeting user expectations in openSUSE while providing the stability in SLE that comes from using a well-tested and not-bleeding- edge kernel. As long as the needs are met (either through a choice of "core kernel" or "more current kernel" (or even "bleeding-edge kernel" for that matter), I think we'll meet the needs of most users without too much trouble. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Wednesday 2015-05-06 10:08, Frederic Crozat wrote:

Le mardi 05 mai 2015 à 17:54 +0000, Jim Henderson a écrit :

...

On Tue, 05 May 2015 09:34:11 +0200, Michal Kubecek wrote:

...

No, it does not. "Support point of view" is something completely different: how well are we able to support the kernel packages. And this would be actually one of the reasons why consider SLE (or SLE based) kernel even if it may be seen "too old" by some.

Well, yes and no. We get users who often ask about how to get the latest kernel on their build because they want new features (not just backported fixes).

Well, SLE kernel doesn't only contains backport fixes, but also backported features.

This is why just thinking in term of version is not good enough anymore..

Tell that to the users... versions count for them, and for some scripts, kernel code, basically everything what was already said last week. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Fredag den 1. maj 2015 12:07:00 skrev jdd:

After the Richard talk at OSC, the status of openSUSE stays unclear, that's normal it have to be discussed, but I see it like this:

* Tumbleweed, the rolling release will the distribution for advanced users * openSUSE? * I new variant (name?) will be more stable, very long time support (at least 3 years), yearly release?

As I see it we basically have two options, if we want a stable release (and we _do_ want a stable release. Surely even the most hardcore bleeding edge people must need something predictable and stable for their girlfriend, parents, work PC, media centre, home server etc.) Option A Based on Tumbleweed, 1 year release cycle, 26 months support (2 releases+2 months). Option B Based on SLE, 1-3 year release cycle(?), 3 years support or more These are the scenarios we should be comparing. Now I have some major reservations about option B. I'm not a packaging expert so I could be wrong about some of them. Option B would be much more work. You would start almost from scratch and you'd need to do a lot of work to backport a reasonable amount of packages/applications to the very basic core that is SLE, to achieve a somewhat attractive general purpose distro. This would already be difficult now that SLE12 is almost "new", 2-3-4 years from now it will be next to impossible I guess. (How long was it between SLE11 and SLE12? 5 years). With a Tumbleweed snapshot you get a pretty decent distro with tons of packages "for free", which can become quite good with a couple of months of feature frozen polishing. As Tumbleweed improves over time, this will become even more true. Option B would create two almost completely separate communities. There would be hardly anything shared between Tumbleweed and SLE based openSUSE. With Tumbleweed based openSUSE you have much more synergy (packaging, howtos, artwork, whatever), because Tumbleweed and openSUSE would be reasonably close. Who will work on SLE based openSUSE? I doubt Tumbleweed packagers will move 3-4 years back in time trying to build stuff. At least some Tumbleweed packagers care about the Tumbleweed based releases, of course mostly around release time when they're still 98% identical to Tumbleweed. Maybe option B would attract some new, different kind of packagers, that care enough about stability and productivity to spend their free time on it, but I think that's pretty unlikely - even Debian packagers barely care about the stable version is my impression. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 7 May 2015 at 00:42, Greg Freemyer wrote:

...

Who will work on SLE based openSUSE? I doubt Tumbleweed packagers will move 3-4 years back in time trying to build stuff. At least some Tumbleweed packagers care about the Tumbleweed based releases, of course mostly around release time when they're still 98% identical to Tumbleweed.

Martin,

I think you are missing a big part of the picture: SLE Point releases: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Suse_distributions

So SLE 11 and 12 point releases came out

11.0 2009-03-24 11.1 2010-06-02 11.2 2012-02-29 11.3 2013-07-01 12.0 2014-10-10

As I understand it SLE Core would be updated with each point release. And those point releases are rather all inclusive so you often get a new kernel and software stack.

So SLE core would not be 3-4 years behind Tumbleweed as I understand it.

If SLE Corp is indeed the future base for openSUSE releases, then shouldn't the release schedule for openSUSE be based on SLE Core updates?

Meaning the above dates plus some time to formalize an openSUSE release around them. Or if SLE freezes SLE core months in advance of the above, then the openSUSE release could even preceed the point releases.

That's something we're certainly considering. We might have a situation where openSUSE/OBS gets the SLE sources once they're relatively frozen (eg. Betas) which would enable the community to get building ontop of it before the release of SLE 12.x

When did SLE 12 freeze the kernel version? As I recall it was in the spring of 2014. If X was also version frozen in the spring, openSUSE could have done a summer 2014 release and preceeded SLE 12 by months.

That theoretical timeline is a little on the ambitious side (at least for our first 'new openSUSE' releases) - I think we're going to have to take our time to learn how to build stuff right in this new approach, but yes, broadly speaking, I think you're thinking along the right track and this is the kind of thing I want to see.

What I don't have any feel for is what happens at end of support.

Specifically SLE 11.0 was only supported for 21 months (without upgrading to 11.1). So how would an openSUSE release based on 11.0 be supportable past the 11.0 end-of-support?

To me the best option is to base both the release schedule and the end-of-support schedule on the SLE point release and end-of-support schedules. The trouble with that is support lifetime of SLE point releases isn't fundamentally longer than openSUSE release's supported life.

The way I currently see this working is something like this.. *note all of these dates and version numbers are TOTALLY MADE UP and nothing to with reality, and are just to illustrate the theoretical progression* openSUSE $NewVersion.1 - Based on SLE 12 SP1 - Theoretical Release Q4 this year openSUSE $NewVersion.2 - Based on SLE 12 SP2 - Theoretical Release Q4 2016 Support for openSUSE $NewVersion.1 ends 6 months later (in line with SLE 12 SP1) openSUSE $NewVersion.3 - Based on SLE 12 SP3 - Theoretical Release Q4 2017 Support for openSUSE $NewVersion.2 ends 6 months later (in line SLE 12 SP2) openSUSE $NewVersion+1.0 - Based on SLE 13 - Theoretical Release Q4 2018 Support for openSUSE $NewVersion.3 ends X months later (almost certainly longer than 6 months, to help with transitions) The current value of X that is being kicked around is something like 12 months, but possibly could be as much as 3 years, depends on a combination of factors, like how long SUSE are willing to maintain the Shared 12 SP3 Core, and how long makes sense for openSUSE to maintain our stuff on top of it. So, in short terms, this would mean that each openSUSE $New point release would be supported for at least 18 months (longer if the release takes longer to come out), with the last release having a longer time to handle the transition to the big new codebase. With the exception of the extra long duration of the .3 release, I realise this theoretical scenario might appear to be very similar to the status quo, but by using the Shared SLE Sources, the impact of these 'minor version bumps' will be significantly smaller than openSUSE's old version bumps (where every one was a major jump, every time), so there is a strong case to be made that people should be comfortable jumping in that 6 month window every time. What do you think?

Is openSUSE going to have to start having point releases that match SLE? (can't decide if I like or dislike that idea).

See above, I think it's certainly possible, and I like the idea -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hey, On 06.05.2015 19:09, Martin Schlander wrote:

hardcore bleeding edge people must need something predictable and stable for their girlfriend

Phew. The biggest group of people on this planet that could consume Tumbleweed, or anything else we produce, identify themselves as female and girlfriends. I doubt they will consider doing anything at all with us when they hear how dismissive we talk about them... Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Torsdag den 7. maj 2015 12:46:03 skrev Henne Vogelsang:

On 06.05.2015 19:09, Martin Schlander wrote:

...

hardcore bleeding edge people must need something predictable and stable for their girlfriend

Phew. The biggest group of people on this planet that could consume Tumbleweed, or anything else we produce, identify themselves as female and girlfriends. I doubt they will consider doing anything at all with us when they hear how dismissive we talk about them...

I'm not talking dismissive of them. I'm not a Tumbleweed user myself and never will be (at least not primarily), I need mah stable, frozen openSUSE! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, May 7, 2015 at 4:51 AM, Richard Brown wrote:

On 7 May 2015 at 00:42, Greg Freemyer wrote:

...

...

Who will work on SLE based openSUSE? I doubt Tumbleweed packagers will move 3-4 years back in time trying to build stuff. At least some Tumbleweed packagers care about the Tumbleweed based releases, of course mostly around release time when they're still 98% identical to Tumbleweed.

Martin,

I think you are missing a big part of the picture: SLE Point releases: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Suse_distributions

So SLE 11 and 12 point releases came out

11.0 2009-03-24 11.1 2010-06-02 11.2 2012-02-29 11.3 2013-07-01 12.0 2014-10-10

As I understand it SLE Core would be updated with each point release. And those point releases are rather all inclusive so you often get a new kernel and software stack.

So SLE core would not be 3-4 years behind Tumbleweed as I understand it.

If SLE Corp is indeed the future base for openSUSE releases, then shouldn't the release schedule for openSUSE be based on SLE Core updates?

Meaning the above dates plus some time to formalize an openSUSE release around them. Or if SLE freezes SLE core months in advance of the above, then the openSUSE release could even preceed the point releases.

That's something we're certainly considering. We might have a situation where openSUSE/OBS gets the SLE sources once they're relatively frozen (eg. Betas) which would enable the community to get building ontop of it before the release of SLE 12.x

...

When did SLE 12 freeze the kernel version? As I recall it was in the spring of 2014. If X was also version frozen in the spring, openSUSE could have done a summer 2014 release and preceeded SLE 12 by months.

That theoretical timeline is a little on the ambitious side (at least for our first 'new openSUSE' releases) - I think we're going to have to take our time to learn how to build stuff right in this new approach, but yes, broadly speaking, I think you're thinking along the right track and this is the kind of thing I want to see.

...

What I don't have any feel for is what happens at end of support.

Specifically SLE 11.0 was only supported for 21 months (without upgrading to 11.1). So how would an openSUSE release based on 11.0 be supportable past the 11.0 end-of-support?

To me the best option is to base both the release schedule and the end-of-support schedule on the SLE point release and end-of-support schedules. The trouble with that is support lifetime of SLE point releases isn't fundamentally longer than openSUSE release's supported life.

The way I currently see this working is something like this.. *note all of these dates and version numbers are TOTALLY MADE UP and nothing to with reality, and are just to illustrate the theoretical progression*

openSUSE $NewVersion.1 - Based on SLE 12 SP1 - Theoretical Release Q4 this year

openSUSE $NewVersion.2 - Based on SLE 12 SP2 - Theoretical Release Q4 2016 Support for openSUSE $NewVersion.1 ends 6 months later (in line with SLE 12 SP1)

openSUSE $NewVersion.3 - Based on SLE 12 SP3 - Theoretical Release Q4 2017 Support for openSUSE $NewVersion.2 ends 6 months later (in line SLE 12 SP2)

openSUSE $NewVersion+1.0 - Based on SLE 13 - Theoretical Release Q4 2018 Support for openSUSE $NewVersion.3 ends X months later (almost certainly longer than 6 months, to help with transitions) The current value of X that is being kicked around is something like 12 months, but possibly could be as much as 3 years, depends on a combination of factors, like how long SUSE are willing to maintain the Shared 12 SP3 Core, and how long makes sense for openSUSE to maintain our stuff on top of it.

So, in short terms, this would mean that each openSUSE $New point release would be supported for at least 18 months (longer if the release takes longer to come out), with the last release having a longer time to handle the transition to the big new codebase.

With the exception of the extra long duration of the .3 release, I realise this theoretical scenario might appear to be very similar to the status quo, but by using the Shared SLE Sources, the impact of these 'minor version bumps' will be significantly smaller than openSUSE's old version bumps (where every one was a major jump, every time), so there is a strong case to be made that people should be comfortable jumping in that 6 month window every time.

What do you think?

You seem to be implying the last SLE point release for a major version is supported by SLE for 2+ years. Is that a valid statement? If so, I think this summary of your proposal is accurate: - opensuse implement the same major / point release mechanism that SLE uses - After new point releases, opensuse users would have 6 months of support in which to transition to the new point release - After major releases opensuse users would have 12 months (or more) of support minimum to allow a scheduled transition ==== Pros - it puts us in sync with SLE and allows us to leverage SLE Core Cons - it is no longer possible for an opensuse user to skip a release. ie. the overlapping support in the current model allows someone running a stable setup to only upgrade every other opensuse release and still maintain support the who time. === Questions 1) I don't know what the SLE major upgrade support policy is, but is it feasible to have opensuse support the last point release of a major release until at least 6 months after the next point release. ie. Support the last 12.x release until 6 months after 13.1 is available. That way even if 13.0 turns out to have major problems, one can hope they are resolved in the first 13.1 point release. 2) How would Evergreen fit in? Does it disappear? Does it extend the support of the last point release in a major series only? === Thoughts: I don't want to be forced to upgrade a server to a .0 release (in the new naming convention). If the 13.0 / 14.0 / etc major releases can be skipped by opensuse users needing stability on servers/etc, I like this proposal. If not, I don't. I don't care if enabling .0 major release skipping is enabled via normal openSUSE support of only via Evergreen support. I just want that option. Greg . -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 07.05.2015 um 19:39 schrieb Bruno Friedmann:

On Saturday 02 May 2015 00.26:23 Stephan Kulow wrote:

...

Am 01.05.2015 um 23:32 schrieb Wolfgang Rosenauer:

...

If the project finally agrees to have something more stable and longer maintained and the approach of service packs every 12 months is

And this is the key point. We have to decide for ourselves, what we want to achieve with openSUSE releases. And if we go there, we have to live with the consequences - i.e. accepting the patch madness SLE packages can be.

Greetings, Stephan

Excuse my ignorance, being not that much impacted by SLE in my day life. For making it clear to the community, I guess that some part of what happen during a normal SLE cycle should be published, so the community, knows what kind of consequences we would have to live with.

What is madness? Updating a package (like kernel 3.0 introduction) or never update something and increase its patch numbers until it look like The Tower of Pisa?

I think he meant "patch madness" which I always can feel quite a bit when an Evergreen release gets older (around after 2,5 years or so) and you want to do security updates on the old stuff. And this will probably affect openSUSE when we want to maintain additional stuff on top of the SLE core (at least). Wolfgang -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/07/2015 01:39 PM, Bruno Friedmann wrote:

On Saturday 02 May 2015 00.26:23 Stephan Kulow wrote:

...

Am 01.05.2015 um 23:32 schrieb Wolfgang Rosenauer:

...

If the project finally agrees to have something more stable and longer maintained and the approach of service packs every 12 months is

And this is the key point. We have to decide for ourselves, what we want to achieve with openSUSE releases. And if we go there, we have to live with the consequences - i.e. accepting the patch madness SLE packages can be.

Greetings, Stephan

Excuse my ignorance, being not that much impacted by SLE in my day life. For making it clear to the community, I guess that some part of what happen during a normal SLE cycle should be published, so the community, knows what kind of consequences we would have to live with.

What is madness? Updating a package (like kernel 3.0 introduction) or never update something and increase its patch numbers until it look like The Tower of Pisa?

The basic premise is that the underlying version does not change for many years. Patches are applied to fix bugs (security and others) and in the case of the kernel do hardware enablement. Historically there were no version upgrades to packages that are considered "core", period. Version upgrades to things outside of core were rare. In SLES 11 that changed with the kernel being upgraded from 2.6.32 to 3.0.13 when SLES 11 moved from SP1 to SP2. There is lots to read about that [1] if you care to. So if we stick to the kernel as an example as this is probably the most popular and was also picked on in other threads it amounts to the fact that a few thousand patches may accumulate. One can describe that as "patch madness" Looking at more recent things. For SLE 12 the base version of the kernel is 3.12. However, this kernel has many features from kernels that were released later plus bug fixes etc. Currently the patch count for this kernel is around 5500. There will be no version upgrade for the kernel for SP1, thus the number of patches will continue to grow. For the kernel patches are organized in categories and things are tracked in a specific file (series.conf). For other packages things work in similar ways, i.e. the base version stays the same and then patches are applied. However as the upstream development does not progress as fast as the kernel, patch counts for glibc and other core components of a Linux system are much lower. For glibc the patch count is around 60 at the moment, for example. Anyway to make a long story short, the key points are probably: - - Base versions in SLE rarely change (compared to openSUSE) - - New features and bug fixes are provided via patches rather than version upgrades - - More patches implies additional effort to track stuff And just for comparison the current version of glibc in 13.2 carries about the same amount of patches than the version in SLES 12. The kernel in 13.2 has an order of magnitude fewer patches (537) than the SLE kernel. Later, Robert [1] https://plus.google.com/+SUSE/posts/2Pc4wqYCuiu - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVS+jVAAoJEE4FgL32d2Uk3QcH/jB9OPy+NKTTrK6f1Ovzsu9K UqAldGHhYHKeQWt4xvrxkT6x1z6Gq8SgEk797jc+pMckVqh62RWI31QKdipqiMMv E1aqv7qwMsThkMkvWoE12cQURStJdW9SfgeYNanh/HdJa7qr5JjCV9rMV1KVmWN9 mXK4+70I6AMbVQYLMAMm93dk20rDH7yNps4YBbmqo30yxk1w127Fo64hYq9ePDQv xXHtg0p7lJQ/M8fsA6E6TI1JmrA4jKoPWmzKZ3DCSvB5n1jdBj5Nu1XW7JKaCeZD x4qlsiMshGO0MejZtR9ruqU7bqQXzEvcQKMQBfVZavUg0npYEb2qU7VInqUXCkk= =s+8W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/07/2015 12:38 PM, Martin Schlander wrote:

Onsdag den 6. maj 2015 18:42:27 skrev Greg Freemyer:

...

...

Who will work on SLE based openSUSE? I doubt Tumbleweed packagers will move 3-4 years back in time trying to build stuff. At least some Tumbleweed packagers care about the Tumbleweed based releases, of course mostly around release time when they're still 98% identical to Tumbleweed.

I think you are missing a big part of the picture: SLE Point releases: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Suse_distributi ons

So SLE 11 and 12 point releases came out

...

11.0 2009-03-24 11.1 2010-06-02 11.2 2012-02-29 11.3 2013-07-01 12.0 2014-10-10

As I understand it SLE Core would be updated with each point release. And those point releases are rather all inclusive so you often get a new kernel and software stack.

So SLE core would not be 3-4 years behind Tumbleweed as I understand it.

Really? I don't know too much about the SLE service packs, but it's my impression that they're not that exciting and don't upgrade too much stuff. Particularly not from a desktop user point of view.

With the introduction of modules [1] in SLES 12 that have their own life cycle and version change rules service packs in SLE 12 will be more "exciting" than service pack releases in the past. For stuff that is considered "core" we will end up with version numbers that are way behind Tumbleweed. However that does not necessarily mean that the features are also way behind, this will very much depend on the package (see another reply to this thread for more details). Later, Robert [1] https://www.suse.com/communities/conversations/modules-bridging-gap-turt le-hare/ - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVS/bCAAoJEE4FgL32d2UkPSIIALxuuo5YBYbk/AWEXax9I4n9 hd8CJv4o+5G52CLZMDGO1VoB7GRA1nHypqVjKXMrYJkIsWtTNK8OnQmh72QFyqwN mteAVocz1v7CoeXgmvS82tIZtOAMSu8+kkQy7hGrjCz/WI7WPrUQ+IloY4cow+SI xCDyG/UEHp8r450lv/+jZ3Jvq0lL6qjqi9yofuh3BXvFdOvkP9050qXmN4sEnIpd s94Y3NlvIpPqCbRq9AQF2embaQ7B/4B/MCe6aGGsk3eRa0PKxk2LYAlD7azngflZ 2SiAX81wsij67cSnmwYVcHVp2UfXx90fuTOwtC09rpYw7YEuH0myv7KIKh4j3RQ= =qWFm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.05.2015 19:39, Bruno Friedmann wrote:

What is madness?

Well, madness is a very strong word. Let's say it needs high level of concentration to understand https://build.opensuse.org/package/view_file/openSUSE:13.2:Update/systemd/sy... Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlVMdN0ACgkQwFSBhlBjoJbQ5QCfaPemtI8eibeWi2lZMlSfSiU9 p/gAoNWcK0dDJT5ulwpWKIOaQir/9Q3r =0FSA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Le 08/05/2015 11:18, Bruno Friedmann a écrit :

Thanks all for your valuable inputs.

As the recent "thread" about for example systemd, I wonder how much community resources it could consume. And what is the best balance?

yes, too much unuseful rant and not enough concrete work :-(

What's pretty sure :

- on marketing side, it could be harder to become hot with a version number of the package that seems old.

but who in the earth wonder of a package number? certainly not a basic user. certainly not me (out of fearing new stuff)

a big task of education and communication. Explaining correctly to a user that has a too much new hardware, when to apply for another kernel (kernel:stable) and what will be the related consequences.

very easy: if the hardware is newer than the distro, it may not work...we need probably more easy to find and more acurate hardware lists (I always take time to find printer list) IMHO most of the help provided on Linux lists (not only opensuse) is too much technical. nobody should have to recompile a software.. or at least nobody that need an explanation :-) in fact may be we too much rely on our excellent infrastructure and do not make enough effort on the beginners part of the doc. may be or may be not :-) jdd -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org