[opensuse-project] After the Richard talk... what's new for openSUSE
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 -- 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 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
On 1 May 2015 at 12:32, Carlos E. R. <carlos.e.r@opensuse.org> 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
-----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
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). 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-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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-02 10:29, Michal Kubecek wrote:
On Sat, May 02, 2015 at 04:06:54AM +0200, Carlos E. R. wrote:
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.
Well, true, those modules are opensource and you can adapt them if you need and know how. But I did not refer exactly to those modules, but to the whole package, taking vmware as an example. Proprietary products generally take longer to adapt to changes in Linux, that was my point. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVFIOcACgkQja8UbcUWM1xApgEAj1HzfwoiL1yBbX665vppvaIW KNiZYcjCSBl3R6VMCVUBAJoOoKsCOzhIW33N/GhiuZ09NKoW66wgBvJTjXZVF1wg =YwYV -----END PGP SIGNATURE----- -- 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
* jdd <jdd@dodin.org> [05-02-15 15:28]:
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.
can you or somebody else make sure that virtualbox runs on tumbleweed? I don't care of recompiling the module, but I want virtualbox :-)
I can verify that vb does run on tw. I have experience with many versions and many distros running within vb on tw. But I cannot verify the current tw, 20150430, and the current vb, ???, as I have little current need for vb. I do not know why vb would not continue to preform correctly. <rant> But do not get me started on vtrfs1 </rant> -- (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-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Carlos E. R. - 3:19 2.05.15 wrote:
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.
Little off-topic, but I would say that with virtualization the situation is even better. There is alternative - kvm - and it is not worse as in the case of graphic drivers. -- 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
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
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
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
+1 I would like to see openSUSE offer 2 distributions. One rolling release for the cutting edge, stable-but-speedy ie. openSUSE Tumbleweed One regular release for more conservative users - and I think basing it on SLE code is a naturally good choice. a Third distribution, is more than I think we can realistically support or maintain
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
I see this as two related but suggestions - Installable on it's own - I would strongly vote no - this 'installable on its own' would be a 3rd distribution for us to look after, and I think it would directly detract focus from making a 'new openSUSE Regular Release' as stable and exciting as possible. additional components in additional repos (effectively making openSUSE an 'add-on' which we could also provide as a cohesive distribution) - Despite the above, I kind of like this idea, in theory, but I think it makes things more complicated in terms of maintenance.
- Or will this openSUSE dist replace things and create only one repository for that?
I think this is the easiest for maintenance, but requires solid tracking of what we're replacing, so we need to get that answered.
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.
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?
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.
I think we're thinking along the same lines, though if you could explain what you're seeing in more detail, that would be great -- 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
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
On May 1, 2015, at 9:25 AM, Stephan Kulow <coolo@suse.de> wrote:
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
-- 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-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 <martenrt@mlc-wels.edu> 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
Hi, Am 01.05.2015 um 18:26 schrieb Greg Freemyer:
On Fri, May 1, 2015 at 10:51 AM, Robert Martens <martenrt@mlc-wels.edu> 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
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 2 May 2015 at 12:39, jdd <jdd@dodin.org> wrote:
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
yes openQA already tests upgrades - we dont release Tumbleweed snapshots if you cant upgrade from 13.2 to Tumbleweed for example -- 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 13:19, Richard Brown wrote:
On 2 May 2015 at 12:39, jdd <> wrote:
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
yes openQA already tests upgrades - we dont release Tumbleweed snapshots if you cant upgrade from 13.2 to Tumbleweed for example
No, the point is upgrading 11.4 (on evergreen) to 13.1 (will be on evergreen). 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. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVFIjYACgkQja8UbcUWM1yNkAD/Qc21N9FElcIvakf4sWjkkMSt bbY2EOOVz3jK6bfDWrsA/1187ukylk09lkSzBwQQccMOb7reFsShJ3k43i41AbPZ =Jt1S -----END PGP SIGNATURE----- -- 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
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
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 <mkubecek@suse.cz> 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
-----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:
Thanks for posting the link. The official page doesn't have it: <https://events.opensuse.org/conference/osc15/proposal/610> - -- 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
On 2 May 2015 at 01:43, Carlos E. R. <carlos.e.r@opensuse.org> 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:
Thanks for posting the link. The official page doesn't have it:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-02 01:50, Richard Brown wrote:
On 2 May 2015 at 01:43, Carlos E. R. <> wrote: On 2015-05-01 21:22, Jürgen Weigert wrote:
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..
Yep, thanks. :-) I'm watching it now. Just paused it to mention that the left audio channel is almost mute. Very noticeable on headphones. Strange. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVEE8cACgkQja8UbcUWM1w4KgD/auGLKbgDXS3TzBgN+/z1JejS vWxX/51LISs8N/lmiXIA/RAQI1hKQSCFBBfwosi8QE6psgNVG9/YPESpmwWDCGc+ =pyWe -----END PGP SIGNATURE----- -- 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-02 02:15, Jan Engelhardt wrote:
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.
It got much better after some minutes. Only the beginning was bad. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVEHrwACgkQja8UbcUWM1wyUQD/ZpzLhDQKMVc8NYYMz9tB9kSs 31fWC2RD+42PddZD/V0A/27jQd8l+AMuiXSKG3MUAUiD5zxkJAVfTTatuax4kLt2 =jyip -----END PGP SIGNATURE----- -- 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 20:39 schrieb Michal Kubecek:
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.)
While I have to admit that Evergreen could not cover 100% of openSUSE before but really a lot, don't let me estimate but at least we tried to fix everything we got aware of security-wise, I think it could be possible with joined forces. But as I understood the talk I'm not sure if we would have a release every 12 months? We might have a service pack every 12 months but this is tested for upgrade paths and everything. So yes, openSUSE would have much more packages than SLES but openSUSE has it today already, is maintained for 18 months and some maintained by Evergreen even longer. If the project finally agrees to have something more stable and longer maintained and the approach of service packs every 12 months is acceptable for an LTS like thing, it might work out. If this is not the case there is no point in changing anything IMHO. 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 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? -- 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-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 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
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? What's pretty sure : - on marketing side, it could be harder to become hot with a version number of the package that seems old. - on support side, making aware all our supporter on ml, forums, social network about the situation (of all package) their strengths and weakness, will be 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. - maintenance side, reviewing all of them (mean read and understand) will use more packagers, reviewers contribution time. Keep going on, we're drawing our future. -- 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-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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/01/2015 06:26 PM, 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.
Which raises the question whether or not everyone is aware of what "accepting the patch madness SLE packages can be" means. Please speak up if an explanation is desired. 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 iQEcBAEBAgAGBQJVS92rAAoJEE4FgL32d2Uk+wEIAJ3wpHosKvw6IWL5hYLNAbmy Jlt78pCoRPsA0Sl82By797a76n3BvVnWAP8Xl2w1pf2U0bNYC1Ahmcad2iXFIUAO lBLOTQAptpT39p7ynG6B3iT5XbJiyRn8alvhr8rXHoXi/te/UJqoCoDXF+cicgOd 8VAnpITbEmSkhY3oLzE8o6RQKuV99hcL9faRcVNFV5m1BeKIrGgLATP4sZk6Hsaw F1UPsP4Bf/IRwIhMwm2C+w5eMjg7M8SY5irce4rRSrfI5HLw6hVlPIzQOAO7lcwO UHrsofRLZ0H48x71kiUPh1Q9idAH4ORvq5ERlpzap2twga3N77rcRntr4pLYvFk= =oehU -----END PGP SIGNATURE----- -- 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 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?
The "those who do, decide" does not always work. Then we need to come up with a policy what "those who do" really have to deliver afterwards. Because with openSUSE currently "those who do" do not always care shit about their stuff after a few month anymore. (Hereby I excuse myself to everyone who does not act like this! But I guess you get the point.) So everyone wanting to update/replace a component must provide maintenance for the period which still need to be defined because 18 months is something out of question at least for me.
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.
I think we're thinking along the same lines, though if you could explain what you're seeing in more detail, that would be great
Hmm, if I would see more details ;-) So while updating stuff provided already in SLES is unavoidable for openSUSE and in some cases for sure wanted it should not be the main focus because it will again cause extra work for everyone. A "new openSUSE" still should be around as big as now. So there is still plenty of work to provide all these additional packages. I just want to avoid to deviate too much from what we now get as a baseline. I guess I cannot explain it better atm. 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 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
just my understanding
jdd
@ Richard.: Thanks for this talk. That is what we, "invis-server.org" (an openSUSE based open-source small business server project), are waiting for. A more stable regular openSUSE with longer release cycles and longer maintenance would help us to create a more serious server product. Tell us, if we could support this new "unnamed project". Stefan -- www.invis-server.org Stefan Schäfer Ludwigstr. 1-3 63679 Schotten -- 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
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. -- 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
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 -- 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 <oldcpu@opensuse-forums.org>:
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 05/04/2015 11:52 PM, Luiz Fernando Ranghetti wrote:
2015-05-04 15:56 GMT-03:00 oldcpu <oldcpu@opensuse-forums.org>:
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. That raises some support implementation questions in my mind. From a support perspective, I assume that any user who needed to do such (because the openSUSE/SLE common kernel did not support their newer hardware) would then be compelled to custom build their graphic driver (if using a higher performance proprietary driver) and their virtual box (if using the proprietary virtual box) . I doubt there would be rpms of proprietary drivers packaged for Kernel:Stable. Fortunate opensource drivers are better today than in the past (case in point - wireless) but I suspect installing one's proprietary graphic driver "the hardway" or rebuilding proprietary virtual box (with "/etc/init.d/vboxdrv setup" or possibly building the binary) could be a challenge to some new openSUSE users ... Which makes me think if a common kernel approach is adopted, we may want a new wiki / guide for such users (ie how to maintain one's "Kernel:Stable" ) ... and possibly the "Kernel:Stable" may need testing further than what it gets now ? < unsure > . Would "Kernel:Stable" nominally get the same security fixes that the regular openSUSE/SLE kernel gets ? Would it get the same bugzilla support if a bug encountered ? Lee -- 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 <oldcpu@opensuse-forums.org>:
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-04 20:56, oldcpu wrote:
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.
... I agree with you.
Would applying a Tumbleweed kernel be the only way to address such an older kernel concern ?
Or from the Kernel:Stable repo, as has already been suggested. But this assumes that the user managed to install the system... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVH9v0ACgkQja8UbcUWM1xZMAD/WaP8Kdjl9VNteOrklzvqZOPR dsO9bKITgrzbiKeNPoYA/3ncX9tYiPG9RqygdzJrq69/UCIe3Q5x41rjMItCZfIl =3Xv3 -----END PGP SIGNATURE----- -- 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
On 05/05/2015 09:34 AM, 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.
Michal Kubeček
Thank you for considering this aspect wrt the kernel. I suspect we have different interpretations wrt the word 'support', and I should have been more clear. When an install fails, or when an installed openSUSE has difficulty with issues relating to drivers, on the openSUSE forums we often are asked to help and provide the user 'support' to resolve their problem. Clearly this is often different from the SLE/openSUSE developer/packager provision of "support". Further, I note that there are few regular users (and even less beginner users) who can patch and custom compile their kernel to incorporate a feature (with newer hardware support) from a new upstream kernel. Fortunately, the openSUSE packagers are currently very at finding a good balance wrt the kernel version selection in each openSUSE version (reducing the average user requirement for openSUSE kernels with newer hardware support). If by openSUSE distribution adopting an older SLE kernel version also means inclusion of upstream patches (to address new hardware which are nominally only in a newer kernel) as part of the current nominal everyday SLE kernel implementation and support approach, then my query is addressed. Or if Kernel:Stable provides the same , with provision that the community can help new users install such, and keep such running (wrt propriatary drivers, virtualization, etc ... ) then that also addresses my query. I suspect many of us who monitor the openSUSE mailing list are not familiar with the details of SLE wrt kernel maintenance and support, and either a short explanation, or a simple pointer to where we could learn about such, so to provide better understanding and hence better contribution, may also be useful. Kindest regards, Lee -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Tue, 2015-05-05 at 12:59 +0200, oldcpu wrote:
On 05/05/2015 09:34 AM, 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.
Michal Kubeček
Thank you for considering this aspect wrt the kernel.
I suspect we have different interpretations wrt the word 'support', and I should have been more clear.
When an install fails, or when an installed openSUSE has difficulty with issues relating to drivers, on the openSUSE forums we often are asked to help and provide the user 'support' to resolve their problem. Clearly this is often different from the SLE/openSUSE developer/packager provision of "support".
Further, I note that there are few regular users (and even less beginner users) who can patch and custom compile their kernel to incorporate a feature (with newer hardware support) from a new upstream kernel. Fortunately, the openSUSE packagers are currently very at finding a good balance wrt the kernel version selection in each openSUSE version (reducing the average user requirement for openSUSE kernels with newer hardware support).
If by openSUSE distribution adopting an older SLE kernel version also means inclusion of upstream patches (to address new hardware which are nominally only in a newer kernel) as part of the current nominal everyday SLE kernel implementation and support approach, then my query is addressed. Or if Kernel:Stable provides the same , with provision that the community can help new users install such, and keep such running (wrt propriatary drivers, virtualization, etc ... ) then that also addresses my query.
I suspect many of us who monitor the openSUSE mailing list are not familiar with the details of SLE wrt kernel maintenance and support, and either a short explanation, or a simple pointer to where we could learn about such, so to provide better understanding and hence better contribution, may also be useful.
I can try to clarify things. My team is responsible for working with IHVs to ensure we have proper support for latest hardware in our enterprise products. SUSE Linux Enterprise Server/Desktop would not be a viable solution if customers couldn't install on latest hardware. We enable new hardware support using a balance between kernel patches that go out with maintenance updates and updated drivers via extra kernel module packages. At service pack time we integrate the latest driver versions as well as more intrusive hardware changes into the kernel. This allows for the SUSE Linux Enterprise kernels to install and use new hardware as it's introduced to the market. Certain specific new features, or optimizations, which are too intrusive to include as a maintenance update, typically come with the next service pack where we can integrate and thoroughly QA (together with our partners) reducing risk of regression to customers running legacy hardware. An important point to note is that when we do add new hardware support, we work closely with the our partners for testing to ensure proper functionality - and when things do break or slip by QA (which does happen) it's a priority to get fixes out to our customer base. That could be a value to the openSUSE users. All that said, because of our core customer base, we do have a focus on server hardware, and provide the best support there. Desktop/mobile can have some gaps. Hardware not targeted for enterprise customers hasn't seen much attention - basically because we are customer demand driven. If the openSUSE community is interested in leveraging the SUSE Linux Enterprise kernels, I believe that SUSE would strongly consider and evaluate any requests for changes in how we build our kernel to close any gaps to help the community with their needs. I'm pretty confident that we can find ways of making this "older kernel" not so much of an issue for hardware support needs of the openSUSE users. Of course if you want the bleeding edge stuff ASAP, tumbleweed is the way to go. -Scott
-----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
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.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/06/2015 06:58 AM, Jan Engelhardt wrote:
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.
I agree. If someone does a review of openSUSE they are going to run "uname -a" to figure out the kernel version. The story that will be written is that openSUSE comes with a really old kernel. No one writing up a review will go through the trouble to understand the back porting model. Then there will of course be people that cry foul, and rightfully so. However, perception is reality and openSUSE will very quickly be labled as the community distribution with the "really old kernel" even if that is not technically correct. 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 iQEcBAEBAgAGBQJVS+06AAoJEE4FgL32d2UkLHQH/AhMFw/09F4k0sOs2tzep0Wn G8sRqbLhQZWzm0KodnrF2jX0b2EphzkFRyBS9MOsqE5kSv/FWnHzA8L9bRht2mQb j20KoT4JrzglLYa2HAd1Ln/U1w7nh44mxgWeoG7YJLg3XEWPk7i/vQzFtOdyPg5U VCWwObm5a3gt/4vdiuUsh9FVkCpZXfWiDypNYSSHWZbCzfWBB4JNs0y7nGk6qXVn sXVB+S+wEPyrGK8sjS3EP7DpEmvJPiMyo/kLZ+7ntt7OTbtL0isaMMRs2WiBvVLr OnIbdD4A4ioYYq+3SiHZc+/rjYSm6IiCMWNqSOg6FXo+bCkxJBPXHgh9B6OzTAQ= =rWQT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am 08.05.2015 um 00:54 schrieb Robert Schweikert:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2015 06:58 AM, Jan Engelhardt wrote:
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.
I agree. If someone does a review of openSUSE they are going to run "uname -a" to figure out the kernel version. The story that will be written is that openSUSE comes with a really old kernel. No one writing up a review will go through the trouble to understand the back porting model.
Then there will of course be people that cry foul, and rightfully so. However, perception is reality and openSUSE will very quickly be labled as the community distribution with the "really old kernel" even if that is not technically correct. I think there are users who are looking for a stable openSUSE with a kind of long term support. For these users the kernel version doesn't matter. For myself, I have openSUSE installed on all my computers. I use these computers for working and not for playing around. I don't care about the version number of the kernel or anything else. It has to work and has to be stable, that's all.
Another point of view is our project "invis-server". We are developing an openSUSE based small-business server product. If we heard first of the possibility that there will be a free SUSE Linux Version with a SLE Core, that was something we are waiting for years. Without such a SUSE Version, there's no future for our project. If we fear any reviews at "Heise open" or "linux magazin", then the only thing that has to be done is to give such a SLE based openSUSE the right name. A name which points at the intention to build a stable openSUSE for long term use. Stefan
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
iQEcBAEBAgAGBQJVS+06AAoJEE4FgL32d2UkLHQH/AhMFw/09F4k0sOs2tzep0Wn G8sRqbLhQZWzm0KodnrF2jX0b2EphzkFRyBS9MOsqE5kSv/FWnHzA8L9bRht2mQb j20KoT4JrzglLYa2HAd1Ln/U1w7nh44mxgWeoG7YJLg3XEWPk7i/vQzFtOdyPg5U VCWwObm5a3gt/4vdiuUsh9FVkCpZXfWiDypNYSSHWZbCzfWBB4JNs0y7nGk6qXVn sXVB+S+wEPyrGK8sjS3EP7DpEmvJPiMyo/kLZ+7ntt7OTbtL0isaMMRs2WiBvVLr OnIbdD4A4ioYYq+3SiHZc+/rjYSm6IiCMWNqSOg6FXo+bCkxJBPXHgh9B6OzTAQ= =rWQT -----END PGP SIGNATURE-----
-- www.invis-server.org Stefan Schäfer Ludwigstr. 1-3 63679 Schotten -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Wed, 06 May 2015 10:08:58 +0200, 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..
Ah, I see - thanks for the clarification, Frederic. It's good to see you and Scott out here to help the community understand how this all might fit together. :) 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
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
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. 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. 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. Is openSUSE going to have to start having point releases that match SLE? (can't decide if I like or dislike that idea). Greg -- 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 <greg.freemyer@gmail.com> 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
Am 07.05.2015 um 10:51 schrieb Richard Brown:
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?
This depends on the impact of an SLE service pack. I would expect it's not that much of a hassle since SUSE has a strong interest to make it smooth to the SLE customers as well. I personally have no real experience with SP upgrades though but heard that SLES11 SP3 was not that smooth. So this plan might work. 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: SHA256 On 05/07/2015 01:51 AM, Richard Brown wrote:
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 ... What do you think?
I think you could make the concerns about moving 'forward' to an older kernel moot, by trying to get back on track with SLE versions. $NewVersion.1 -> 12.4 $NewVersion.2 -> 12.5 $NewVersion.3 -> 12.6 $NewVersion+1.0 -> 13.3 By 14.0 it'll sort itself out :P - -- James Mason Technical Architect, Public Cloud openSUSE Member SUSE jmason@suse.com - ------------------------------------------------------------------------ SUSECon 2015: Register at susecon.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVS4OIAAoJEBs5UYhsRJAjgd8H/R67R8edqH1B2WPhr9Ppmoyc E+lSG+H4Moqu2YcvL6xWCv2N2gRIlPfUYvme3GL3qL2+jZWhvggsGws7qlrfn6eX 14qFBhwQMcQ4Po1xGSKiH0JCL+e3C6Dj3DQon7SwCIZ6L4HeZkHrczw1N1IcAnl6 6ZTAh4oZCymm4OW9Y6YSiwHG6+xYErHxQR4MpB0GmauK8wjf0aQ4Hux2NwukhMwj zzES1Jx2qCLzif6HR7UbwPGlruoQwRoCgxP3EbKI0NvaOEb6OiZvf0oCG/AC2OXe jvWJ0rO4EshqNjdF73GO5V1EK73Iae1JVGiXGpK0QDQRjKHlMZpEFv/hP9YVa+4= =IW96 -----END PGP SIGNATURE----- -- 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 <RBrownCCB@opensuse.org> wrote:
On 7 May 2015 at 00:42, Greg Freemyer <greg.freemyer@gmail.com> 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
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_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.
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. -- 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
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
Martin Schlander wrote:
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!
Apologies for not being overly constructive above what to do with the SLE source. Martin has hit the nail on the head - we need a stable release for people who just want to get some work done - girlfriends, wives, husbands, children, parents, grandparents, employees, work PC, media centre, home server. My media centre is my personal nightmare - I don't dare touch it, I don't want to upgrade mythtv only to find out that every mythtv client box needs upgrading too. -- Per Jessen, Zürich (16.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
participants (27)
-
Bruno Friedmann -
Carlos E. R. -
Carlos E. R. -
Frederic Crozat -
Greg Freemyer -
Henne Vogelsang -
James Mason -
Jan Engelhardt -
jdd -
Jim Henderson -
Jürgen Weigert -
Larry Finger -
Luiz Fernando Ranghetti -
Martin Schlander -
Matwey V. Kornilov -
Michal Hrusecky -
Michal Kubecek -
oldcpu -
Patrick Shanahan -
Per Jessen -
Richard Brown -
Robert Martens -
Robert Schweikert -
Scott Bahling -
Stefan Schäfer -
Stephan Kulow -
Wolfgang Rosenauer