[opensuse-factory] Progress report about openSUSE release
Hi, As I'm away the next 2 weeks I wanted to share the progress so far. I setup openSUSE:42 with some source required to build SLE sources as openSUSE release. Those SLE sources are linked in a SLE12-Picks subproject to make it easier to see what's coming from where. We have Ring 0 and Ring 1 building and Ring 1 has a DVD built too. It's not yet through openQA[¹], but I tried it locally and the installation looks like openSUSE 13.2 ;) I don't think it makes sense to blend in Factory into this as both the life cycle and the use case of this release will be different, so I would actually start with a rather small distribution and accept inclusion requests independent from Factory (but sources will have to be in Factory too). But we need to make sure Factory copies within O:42 don't out-date too quickly. A word on the version: openSUSE:42 is basically the working title of this parallel code stream mixing SLE12 and openSUSE sources. But we would release snapshots of this as openSUSE releases, I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it. See you refreshed in June ;) Greetings, Stephan [1] http://s.kulow.org/core-qa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Have a good break! On Fri, May 22, 2015 at 7:23 AM, Stephan Kulow <coolo@suse.de> wrote:
Hi,
As I'm away the next 2 weeks I wanted to share the progress so far. I setup openSUSE:42 with some source required to build SLE sources as openSUSE release. Those SLE sources are linked in a SLE12-Picks subproject to make it easier to see what's coming from where.
We have Ring 0 and Ring 1 building and Ring 1 has a DVD built too. It's not yet through openQA[¹], but I tried it locally and the installation looks like openSUSE 13.2 ;)
I don't think it makes sense to blend in Factory into this as both the life cycle and the use case of this release will be different, so I would actually start with a rather small distribution and accept inclusion requests independent from Factory (but sources will have to be in Factory too). But we need to make sure Factory copies within O:42 don't out-date too quickly.
A word on the version: openSUSE:42 is basically the working title of this parallel code stream mixing SLE12 and openSUSE sources. But we would release snapshots of this as openSUSE releases, I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
See you refreshed in June ;)
Greetings, Stephan [1] http://s.kulow.org/core-qa -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Sincerely, Bob Martens Webmaster/Technician Martin Luther College http://mlc-wels.edu -- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22.05.2015 14:28, Robert Martens wrote:
Have a good break!
Hi, I'm back, but I will digest this thread only tomorrow :) Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlV1ihIACgkQwFSBhlBjoJba9wCfXd+dliHxbIzLL55mgT9mvxUi d/IAmgKW0N2WpUUeVu4QbdDDWSCFWVNh =p7BH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 22 May 2015 14:23:16 +0200, Stephan Kulow wrote:
I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
Not to bikeshed, but personally, I like it. Notwithstanding the Hitchhiker's Guide reference, but the history of the numbers "42" in the SUSE world - SUSE Linux 4.2 being the first release, YaST's first version being 0.42 (which were, as I understand it, references to "The Answer"). Given this is a shift in release strategy, as a new generation of openSUSE releases, this variation on the traditional "starting point" for SUSE versioning makes sense. Not to mention that it's SLE release + 30. I'm sure there are other numerological correlations that could be made as well, probably even including some that involve the numbers 6, 9 and possibly base 13. ;) In the words of Douglas Adams (referring to the selection of "42"): "42 will do." Enjoy the time off, and early Happy Towel Day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 22 May 2015 15:50:49 +0000, Jim Henderson wrote: [...] (Sorry for the duplicate post here - I had posted without a subscription and received a reply saying I needed to be subscribed, so I subscribed and posted again. Apparently my held post was just released) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Funny it is. openSUSE plans to provide just another CentOS (SLE rebuild with Factory packages instead of RHEL/Fedora) but guys are arguing against the distro version! Are you kidding me? 9 month openSUSE releases were best of stable and fresh linux distributions. People decided to get them every year and it became more stable and less fresh. The balance was broken. Then Factory suddenly became cool but rolling distribution. And finally openSUSE releases are decides to be yep just another CentOS. Of course it should be again more stable but also it would provide too old base packages. Now SLE12 is rather fresh distro but it provides old gcc version 4.8 that provides ugly C++11/14 support. Ha you will say, we will add non-default gcc5 but OBS can't really use non-default gcc so it would be useless. Next year none of frequently updating software updates will be provided. So?.. -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 26 May 2015 22:23:28 +0300, Dmitriy Perlow wrote:
Funny it is. openSUSE plans to provide just another CentOS (SLE rebuild with Factory packages instead of RHEL/Fedora) but guys are arguing against the distro version! Are you kidding me?
Perhaps you missed my other comments elsewhere in the myriad of threads on the topic. Ultimately, I don't really care about the version number. It's got some meaning for people who know it, but as you say, the real nuts-and-bolts of what makes the distro great is what's in it, not what we call it. I merely commented on the version number to wrap a little context around the potential selection based on what I know of it, because there are some people who don't understand the 'significance'. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.05.2015 21:23, Dmitriy Perlow wrote:
Now SLE12 is rather fresh distro but it provides old gcc version 4.8 that provides ugly C++11/14 support. Ha you will say, we will add non-default gcc5 but OBS can't really use non-default gcc so it would be useless. Next year none of frequently updating software updates will be provided. So?..
Why can't OBS use non-default gcc? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Stephan Kulow <coolo@suse.de> Tue, 09 Jun 2015 11:57:26 +0300:
On 26.05.2015 21:23, Dmitriy Perlow wrote:
Now SLE12 is rather fresh distro but it provides old gcc version 4.8 that provides ugly C++11/14 support. Ha you will say, we will add non-default gcc5 but OBS can't really use non-default gcc so it would be useless. Next year none of frequently updating software updates will be provided. So?..
Why can't OBS use non-default gcc?
Greetings, Stephan
http://lists.opensuse.org/archive/opensuse-packaging/2014-12/msg00053.html -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 22 May 2015 14:23:16 +0200, Stephan Kulow wrote:
I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
Not to bikeshed, but personally, I like it. Notwithstanding the Hitchhiker's Guide reference, but the history of the numbers "42" in the SUSE world - SUSE Linux 4.2 being the first release, YaST's first version being 0.42 (which were, as I understand it, references to "The Answer"). Given this is a shift in release strategy, as a new generation of openSUSE releases, this variation on the traditional "starting point" for SUSE versioning makes sense. Not to mention that it's SLE release + 30. I'm sure there are other numerological correlations that could be made as well, probably even including some that involve the numbers 6, 9 and possibly base 13. ;) In the words of Douglas Adams (referring to the selection of "42"): "42 will do." Enjoy the time off, and early Happy Towel Day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 22.05.2015 um 14:23 schrieb Stephan Kulow:
Hi,
As I'm away the next 2 weeks I wanted to share the progress so far. I setup openSUSE:42 with some source required to build SLE sources as openSUSE release. Those SLE sources are linked in a SLE12-Picks subproject to make it easier to see what's coming from where.
We have Ring 0 and Ring 1 building and Ring 1 has a DVD built too. It's not yet through openQA[¹], but I tried it locally and the installation looks like openSUSE 13.2 ;)
I don't think it makes sense to blend in Factory into this as both the life cycle and the use case of this release will be different, so I would actually start with a rather small distribution and accept inclusion requests independent from Factory (but sources will have to be in Factory too). But we need to make sure Factory copies within O:42 don't out-date too quickly.
I only understand half of what you wrote actually since OBS distro projects are black magic to me. My main question: - where to download the DVD image - and in which repo I get changes/updates? ;-) Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 May 2015 at 11:29, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Hi,
Am 22.05.2015 um 14:23 schrieb Stephan Kulow:
Hi,
As I'm away the next 2 weeks I wanted to share the progress so far. I setup openSUSE:42 with some source required to build SLE sources as openSUSE release. Those SLE sources are linked in a SLE12-Picks subproject to make it easier to see what's coming from where.
We have Ring 0 and Ring 1 building and Ring 1 has a DVD built too. It's not yet through openQA[¹], but I tried it locally and the installation looks like openSUSE 13.2 ;)
I don't think it makes sense to blend in Factory into this as both the life cycle and the use case of this release will be different, so I would actually start with a rather small distribution and accept inclusion requests independent from Factory (but sources will have to be in Factory too). But we need to make sure Factory copies within O:42 don't out-date too quickly.
I only understand half of what you wrote actually since OBS distro projects are black magic to me. My main question: - where to download the DVD image - and in which repo I get changes/updates?
;-)
Thanks, Wolfgang
I'll try and decode en_Coolo into en_GB We have the earliest Pre-Alpha, incomplete images built for openSUSE 42. They're probably useless for any 'real work', but are a good starting point for testing. They're using the SLE Sources with openSUSE branding and currently contain only what we know as 'Ring 1' (ie. Everything required to install a Minimal X installation, but no other packages) You can see the results of the first tests of this image in openQA - http://s.kulow.org/core-qa Where do we go from here? For Package Maintainers: Coolo's suggestion is to have openSUSE 42 as a separate project in OBS, and not automatically inherit anything from Factory, so people will need to submit to the openSUSE 42 Project in OBS - https://build.opensuse.org/project/show/openSUSE:42 . I don't know how ready we are for that just yet, with coolo on vacation I'd expect nothing will really move in this area for the next two weeks, but I think it's good that people consider this approach, give feedback, get used to how it'll work, etc. For Testers/Bugfixers: Please review the openQA results, file bugs and try and help fix the bugs - For example, it looks like the current image is inappropriately installing the Xen kernel and trying to use it by default - https://openqa.opensuse.org/tests/64041/modules/first_boot/steps/1 For anyone who wants the DVD to play with: You can get it from the 'Download ISO' button from any openQA test results, eg - https://openqa.opensuse.org/tests/64041/asset/3740 As for update repos - Paitence is a virtue, we probably want more of a complete distro before we worry too much about update repos and such ;) Hope this helps, (P.S. I'm also on vacation for the next 2 weeks, so don't be surprised if any replies are few and far between compared to usual) Thanks, Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 23.05.2015 um 11:45 schrieb Richard Brown:
On 23 May 2015 at 11:29, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Hi,
I only understand half of what you wrote actually since OBS distro projects are black magic to me. My main question: - where to download the DVD image - and in which repo I get changes/updates?
I'll try and decode en_Coolo into en_GB
thanks
We have the earliest Pre-Alpha, incomplete images built for openSUSE 42. They're probably useless for any 'real work', but are a good starting point for testing.
agreed
They're using the SLE Sources with openSUSE branding and currently contain only what we know as 'Ring 1' (ie. Everything required to install a Minimal X installation, but no other packages)
For Package Maintainers: Coolo's suggestion is to have openSUSE 42 as a separate project in OBS, and not automatically inherit anything from Factory, so people will need to submit to the openSUSE 42 Project in OBS - https://build.opensuse.org/project/show/openSUSE:42 . I don't know how ready we are for that just yet, with coolo on vacation I'd expect nothing will really move in this area for the next two weeks, but I think it's good that people consider this approach, give feedback, get used to how it'll work, etc.
This needs a better understanding indeed. I haven't checked what is in Ring 1 exactly but I would think that we have the different "package groups" to consider: - packages not in SLE but wanted in openSUSE would mainly be copies from Factory - packages available in SLE which are not Ring 0/1 but wanted on openSUSE would be added and there would be a decision from somewhere if the SLE or a more recent package version should be included Is the above a common understanding? Would be nice to know at some point how the submission workflow looks like especially for the second case.
For anyone who wants the DVD to play with: You can get it from the 'Download ISO' button from any openQA test results, eg - https://openqa.opensuse.org/tests/64041/asset/3740
thanks
As for update repos - Paitence is a virtue, we probably want more of a complete distro before we worry too much about update repos and such ;)
I wasn't really talking about an update repo but the repo I need to add to follow the evolvement of 42. I cannot find anything on download.opensuse.org but that's probably because it also does not exist yet? Reinstalling/updating from a DVD image sounds not very efficient.
(P.S. I'm also on vacation for the next 2 weeks, so don't be surprised if any replies are few and far between compared to usual)
I'm also on vacation but it shouldn't make a difference for me ;-) Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 23.05.2015 um 12:02 schrieb Wolfgang Rosenauer:
I wasn't really talking about an update repo but the repo I need to add to follow the evolvement of 42. I cannot find anything on download.opensuse.org but that's probably because it also does not exist yet? Reinstalling/updating from a DVD image sounds not very efficient.
Something related: Is in coolo's :42 already a method to merge SLE updates? At some point we would freeze obviously but for the moment we probably want to have all released updates? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, May 23, 2015 at 1:02 PM, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
This needs a better understanding indeed. I haven't checked what is in Ring 1 exactly but I would think that we have the different "package groups" to consider: - packages not in SLE but wanted in openSUSE would mainly be copies from Factory
I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability. But then you are in the same situation as today and if there is not enough resources to maintain current openSUSE those resources will not magically emerge by just throwing SLE packages in the mix. Another consideration - how are bug reports supposed to be handled? What happens if I report a bug against SLE package in openSUSE 42? Who is going to handle it? WIll it be merged back in SLE? I doubt very much, because at least some bugs will be caused by interaction with software versions that do not even exist in SLE. But then it means the first problem will make SLE and openSUSE diverge and again mean that the same resources as today are required to maintain it. Having CentOS like rebranded SLE will likely have its user base which is different from current openSUSE or TW, which can be considered as added value. Having mix and match won't be used by those needing SLE stability nor by those needing relatively modern versions openSUSE offers.
- packages available in SLE which are not Ring 0/1 but wanted on openSUSE would be added and there would be a decision from somewhere if the SLE or a more recent package version should be included Is the above a common understanding?
Would be nice to know at some point how the submission workflow looks like especially for the second case.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 24 of May 2015 08:08:42 Andrei Borzenkov wrote:
I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability.
I don't think so. If e.g. konversation crashes, it's definitely unfortunate and annoying but I still see it as a problem of much lower importance than a crashing kernel or a security bug in OpenSSL. So I do see some merit in having a stable base ("core" packages) from SLE (or based on it) and some (less stable) fancy stuff on top of it.
Another consideration - how are bug reports supposed to be handled? What happens if I report a bug against SLE package in openSUSE 42? Who is going to handle it? WIll it be merged back in SLE? I doubt very much, because at least some bugs will be caused by interaction with software versions that do not even exist in SLE.
If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.
But then it means the first problem will make SLE and openSUSE diverge and again mean that the same resources as today are required to maintain it.
Having one or two extra patches doesn't automatically mean you are on your own. Take the evergreen kernel as an example: there are few patches added and the configuration is very different but most of the time, the merge of SLE changes just works; and even if there are conflicts, resolving them is much less work than maintaining a set of kernel packages on my own would be.
Having CentOS like rebranded SLE will likely have its user base which is different from current openSUSE or TW, which can be considered as added value. Having mix and match won't be used by those needing SLE stability nor by those needing relatively modern versions openSUSE offers.
If the new release is going to be (rebranded) SLE packages as core and some non-core packages on top of it, it would actually be a superset of that "SLEntOS". In other words, if you want a "SLEntOS", you could have it by installing only those core packages and none of the extra ones. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Montag, 25. Mai 2015 schrieb Michal Kubecek:
On Sunday 24 of May 2015 08:08:42 Andrei Borzenkov wrote:
I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability.
I don't think so. If e.g. konversation crashes, it's definitely unfortunate and annoying but I still see it as a problem of much lower importance than a crashing kernel or a security bug in OpenSSL. So I do see some merit in having a stable base ("core" packages) from SLE (or based on it) and some (less stable) fancy stuff on top of it.
What about updated core packages? AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]). I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.
Another consideration - how are bug reports supposed to be handled? What happens if I report a bug against SLE package in openSUSE 42? Who is going to handle it? WIll it be merged back in SLE? I doubt very much, because at least some bugs will be caused by interaction with software versions that do not even exist in SLE.
If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.
Nice if condition ;-) What happens if the bug is caused by a package that was updated in openSUSE 42, but not in SLE? (The above example shows that this is something that can happen in practise.) Regards, Christian Boltz [1] Needless to say that I could easily add a "told you so" ;-) - I recommended the 2.9 branch early enough [2] after my patch DoS [3] was reviewed... [3] see http://blog.cboltz.de for details -- [KDE3 vs. KDE4] My guess is the vocal minority will only be satisfied when KDE4 gets dropped. We need to let them know that might happen round about the release of KDE5.4 . [from a comment on http://blogs.warwick.ac.uk/bweber/entry/opensuse_110_kde4/] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 06:15 PM, Christian Boltz wrote:
Hello,
Am Montag, 25. Mai 2015 schrieb Michal Kubecek:
On Sunday 24 of May 2015 08:08:42 Andrei Borzenkov wrote:
I fail to see what advantage arbitrary mix of SLE and non-SLE packages can provide. Doing it you lose the main argument for SLE - extensive QA and long term stability.
I don't think so. If e.g. konversation crashes, it's definitely unfortunate and annoying but I still see it as a problem of much lower importance than a crashing kernel or a security bug in OpenSSL. So I do see some merit in having a stable base ("core" packages) from SLE (or based on it) and some (less stable) fancy stuff on top of it.
What about updated core packages?
AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]).
I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.
That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting. 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 iQEcBAEBAgAGBQJVZPXSAAoJEE4FgL32d2Ukw30H/RYM/47WIYAhxGpWeLs4swBw VJLMZ1vDIkyMPPKZE44Hp6+eyzRfW6hZqqDJulsuXNMRwmRXAJh9lukWpR7Aq7vv 7elpgnBUPegW1WUI1h6IGh6xSadWRlzh3sk816jAp1gWgRtktvvEaWZr0gtMOax7 n2ubJfa0O89M6q3kB8CeDXfGr/nvlmj3MoaeVSotx7PSfRHCEAEoXgdglk2aMyl5 mhZHLlIE/Sd+h/Pi5eJuVDQ6FDUtYDsX+KxVF6JMVk7Dx9DKaqE46fzyDGeTbbxP zpCakO1tQ3468BIO4Q94fj01uS+2U52Eli4vyhaEfY9da50eSgNXdxlYBae13Cg= =MFQo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 00:38, Robert Schweikert wrote:
That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting.
Another point of interest, is that bugzillas against SLE are private by default. Many more bugzillas than currently will have to cross the "frontier" now... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVlO4cACgkQtTMYHG2NR9WL1QCfXYE76VFgahb4H/n1r0B7JI0e 4n8An2VtidQNEBAddWbG2KocYbgH+m6F =C0cL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 00:38, Robert Schweikert wrote:
That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting.
Another point of interest, is that bugzillas against SLE are private by default. Many more bugzillas than currently will have to cross the "frontier" now...
That's a good point. I personally think that it would be good for SUSE to adopt a rule similar to what Mozilla uses, "everything (bug reports in this case) is open [by default], unless there is a really good argument why it should be (temporarily?) hidden from the public". That rule is pretty flexible, and at Mozilla we tend to err on the side of openness when there is doubt, but that can be handled as needed. But I don't see any good reason why bug reports on common and/or FLOSS packages need to be kept closed by default - unless they are security issues, which should be kept closed until a public advisory is published. All that said, the openSUSE community can't decide the policies of SUSE, of course. I'm just saying that I think such a rule would make sense. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 May 2015 at 15:13, Robert Kaiser <kairo@kairo.at> wrote:
Carlos E. R. schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 00:38, Robert Schweikert wrote:
That'll be an interesting experiment. We'll see how this works out. It is a very concrete example of where things can seriously go awry by sticking to "old" stuff. This will be very interesting.
Another point of interest, is that bugzillas against SLE are private by default. Many more bugzillas than currently will have to cross the "frontier" now...
That's a good point.
I personally think that it would be good for SUSE to adopt a rule similar to what Mozilla uses, "everything (bug reports in this case) is open [by default], unless there is a really good argument why it should be (temporarily?) hidden from the public".
That rule is pretty flexible, and at Mozilla we tend to err on the side of openness when there is doubt, but that can be handled as needed. But I don't see any good reason why bug reports on common and/or FLOSS packages need to be kept closed by default - unless they are security issues, which should be kept closed until a public advisory is published.
The default privacy status of SLE bug reports is something pretty high on my agenda to get sorted out, regardless of openSUSE's use of the SLE sources (though, obviously, it makes this even more important) The reason for the current situation is because SLE bug reports often include (potentially private and almost certainly sensitive) customer data. In the past, putting this information in 'Private Comments' in bugzilla was felt to be insufficient, as lots of non-employees also had access to Private Comments, so the only viable option was to make the entire bug Private. However, with the recent changes to SUSE's Bugzilla, this was changed so Private Comments are now only visible to employees. This means I think we've got a great starting point to bring this topic up and hopefully get it addressed. But it will mean changing policies and processes across the whole of SUSE, so I wouldn't expect it to change overnight. I will do what I can to raise the topic though.
All that said, the openSUSE community can't decide the policies of SUSE, of course. I'm just saying that I think such a rule would make sense.
the openSUSE community can't decide the policies of SUSE, but one of the reasons you have the openSUSE Board is to "Communicate community interests to SUSE". I think this qualifies and I'd certainly like to see progress made here. :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.05.2015 um 15:32 schrieb Richard Brown:
In the past, putting this information in 'Private Comments' in bugzilla was felt to be insufficient, as lots of non-employees also had access to Private Comments, so the only viable option was to make the entire bug Private.
That's wrong. It's the other way round. Private comments are only seen by "internal" accounts (basically "@novell.com" login), while private bugs can sometimes be seen by partners and by everyone who is on CC: list.
However, with the recent changes to SUSE's Bugzilla, this was changed so Private Comments are now only visible to employees.
This was always the case. And I know, as I'm using bugzilla with three accounts: external, partner and internal (subcontractor). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 00:15, Christian Boltz wrote:
[2] after my patch DoS [3] was reviewed...
I noticed. So it was you who flooded my email :-P (I just lurk reading the AA list) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVlPh8ACgkQtTMYHG2NR9VJ8QCeIbojNivO/jyheiudterGmC1n VToAn14ot4ZS7elR/Il/1g8GFOBWICJL =hd0q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 27 of May 2015 00:15:31 Christian Boltz wrote:
What about updated core packages?
AFAIK SLE 12 ships with AppArmor 2.8.x which isn't supported upstream anymore, and has totally different code in the aa-* tools (2.8 has perl tools, 2.9 got them rewritten in python, so backporting fixes is basically impossible - and the SLE maintainers already found this out the hard way [1]).
I'm quite sure I'll submit AppArmor 2.9.x(or the soon-to-be-released [2] 2.10) to openSUSE 42 because maintaining 2.8.x would be a pain. Needless to say that this comes with more changes than just the aa-* tools, and might influence other packages in the core.
IMHO in the end it will always be up to the package maintainer(s) to decide if the benefits (both functional and maintenance) of newer package version outweigh losing the easier life of consuming SLE updates. (For leaf packages, that is. For packages others depend on, interest of those will have to be taken into account.)
If the bug affects SLE package and there are no obvious reason not to, I suppose the fix would be included in SLE as well.
Nice if condition ;-)
What happens if the bug is caused by a package that was updated in openSUSE 42, but not in SLE? (The above example shows that this is something that can happen in practise.)
I have a problem with the construct of "a bug in package A caused by package B". I suppose you what you really mean is a bug in core package A that didn't manifest until non-core package B was used with it". I'm afraid there can't be a general rule for this. It will always depend on seriousness of the bug, intrusiveness of the fix and some other factors. After all, we (1) often fix bugs in SLE packages that need third-party software to manifest and (2) sometimes don't fix acknowledged bugs (even those not requiring any extra SW to manifest) with known fix if there are good reasons not to. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 23.05.2015 um 11:45 schrieb Richard Brown:
On 23 May 2015 at 11:29, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote: For Testers/Bugfixers: Please review the openQA results, file bugs and try and help fix the bugs - For example, it looks like the current image is inappropriately installing the Xen kernel and trying to use it by default - https://openqa.opensuse.org/tests/64041/modules/first_boot/steps/1
So yes, the DVD installation does not boot because the xen package is missing but the kernel-xen package is installed. Even worse is that kernel-xen is the only kernel package on the DVD while the remainder of xen is missing. Since I have no idea what needs to happen now and not even know where to report bugs about it I'm pretty much stuck already. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24 May 2015 at 17:11, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
So yes, the DVD installation does not boot because the xen package is missing but the kernel-xen package is installed.
Even worse is that kernel-xen is the only kernel package on the DVD while the remainder of xen is missing. Since I have no idea what needs to happen now and not even know where to report bugs about it I'm pretty much stuck already.
Wolfgang
https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE%20Distribution the Version number would be incorrect, so I'd recommend any bugs filed about the 'next version of the distro' should be tagged with [openSUSE 42] in the Summary field for now -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/05/15 01:54, Richard Brown wrote:
On 24 May 2015 at 17:11, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
So yes, the DVD installation does not boot because the xen package is missing but the kernel-xen package is installed.
Even worse is that kernel-xen is the only kernel package on the DVD while the remainder of xen is missing. Since I have no idea what needs to happen now and not even know where to report bugs about it I'm pretty much stuck already.
Wolfgang
https://bugzilla.opensuse.org/enter_bug.cgi?product=openSUSE%20Distribution
the Version number would be incorrect, so I'd recommend any bugs filed about the 'next version of the distro' should be tagged with [openSUSE 42] in the Summary field for now
Sorry to say but to a normal - as in "sane" :-) - user who accesses this list, this whole thing is beginning to look and sound like a Chinese opera. Or, to literally translate a Russian saying, "Some into the forest , some for firewood...." (Andrei would know exactly what I am saying) as I think it now applies to the development of openSUSE. In English I think that the closest meaning to the Russian saying is, "Helter skelter". (I just clicked, for example, on the URL above just to see what I would see and, firstly, had to get redirected to some other "site" as the URL "has been moved" and, secondly, was asked to provide a login name and password.) Could we, the normal users, be assured that openSUSE will continue to be made available and FUNCTION as well (latest version being 13.2) as we, the normal users, have been accustomed to over the past many, many years? So far the discussion in this list re the future of openSUSE in whatever form, including in the form of Tumbleweed (especially), does not promote positiveness about what may be expected. BC -- Using openSUSE 13.2, KDE 4.14.6 & kernel 4.0.4-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/22/2015 03:23 PM, Stephan Kulow wrote:
A word on the version: openSUSE:42 is basically the working title of this parallel code stream mixing SLE12 and openSUSE sources. But we would release snapshots of this as openSUSE releases, I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 2. It confuses users 3. It is awkward 4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1? Personally I would like to see this new openSUSE to become 14.1. Then we have 2 possibilities: 1. Continue releases in parallel with SLE (SLE 12 SP2 -> openSUSE 14.2 ...... SLE 13 -> openSUSE 15.0 ;) 2. Stick with 14.x until SLE reaches 14 so everything is synced. (Perhaps SUSE would consider skipping SLE 13 to make this happen sooner?) Just my 2c, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
2. It confuses users
I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem. It will lead to questions from our users "Why the big change? What is the difference from 13.2 and before?" and these are *exactly* the kind of questions we want to have our users ask, so we can answer them with very clear messages about the change to the Regular Release, how it will now be based on SLE Sources, how it'll be more stable, with a new schedule, with a new way of being built. I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1?
Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE) As long as we clearly explain the logic and meaning (or lack thereof) behind the openSUSE version numbering scheme, I don't think we're limited in what we can do if an idea like this crops up again. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 May 2015 at 14:24, Richard Brown <RBrownCCB@opensuse.org> wrote:
Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)
I managed to click send without finishing this thought.. ..we could have called it openSUSE 12.4, and kept on just adding 0.1 forever, so we'd be openSUSE 12.7 or so now) at least the proposed new numbering, starting at 42 and keeping in sync with the version of SLE sources used by adding 30 (eg 42.1 would be based on SLE 12 SP1 sources) would mean users would know when there is a major codebase change (43 would be based on SLE 13) and that's going to be something important for people to know going forward. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-23 14:24, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
I would like the openSUSE numbers be the same or very similar to the SLES numbers of the release they base on. That would really mean something and be useful.
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
I have no idea what the number 42 means. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVgdggACgkQtTMYHG2NR9VkbQCfZR338lpPa9dhWL0JN855Yyhs +L0AmgKFlNUlYLjHHW3sz8jX/9KbKyvi =Zoz7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.05.2015 um 14:43 schrieb Carlos E. R.:
I have no idea what the number 42 means. See:
http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Ga... and: https://en.opensuse.org/S.u.S.E._Linux_4.2 Stefan -- www.invis-server.org Stefan Schäfer Ludwigstr. 1-3 63679 Schotten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-23 15:11, Stefan Schäfer wrote:
Am 23.05.2015 um 14:43 schrieb Carlos E. R.:
I have no idea what the number 42 means. See:
http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Ga...
Well,
thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)
Well, the wikipedia disagrees, says the first version was 3/94. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhBwMACgkQja8UbcUWM1y2cAD9G+SEic+tOUfLjDyPqwdSU2m0 dpTn2TrrWdJXKPTlNYoA/io9R+SVCD9I16nXEOAZpx2bmv3gqNOGjqrq5ijkqoKl =jUL6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. schrieb:
Well,
thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)
Actually, it's in complete congruence with the seriousness displayed in the book this is sourced from. And yes, it's just as crazy as some discussions here. If you like those, you surely adore the book.
Well, the wikipedia disagrees, says the first version was 3/94.
No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-24 02:16, Robert Kaiser wrote:
Carlos E. R. schrieb:
Well,
thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)
Actually, it's in complete congruence with the seriousness displayed in the book this is sourced from. And yes, it's just as crazy as some discussions here. If you like those, you surely adore the book.
Mmm.
Well, the wikipedia disagrees, says the first version was 3/94.
No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins
And in <http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Versions> it clearly shows 3/94 as the first one, Slackware based, kernel 1.0 - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhINUACgkQja8UbcUWM1xZQQEAmTpY2/P1tzO+9mCK1dXV9JEB WVx5WXRFFkfZJmVjvHoA/RBNA8kmbguNoJ+hLnKdTrTfSswrEf2jFfdPRf5FGuBO =2IVL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I kind of like the openSUSE 42.1 naming/release number. I also like Hitchhiker's Guide to the Galaxy and the tie-in with the history of SUSE and YaST. On Sat, May 23, 2015 at 7:52 PM, Carlos E. R. <carlos.e.r@opensuse.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-05-24 02:16, Robert Kaiser wrote:
Carlos E. R. schrieb:
Well,
thinking that openSUSE may be the "Answer to the Ultimate Question of Life, the Universe, and Everything", may be preposterous. :-)
Actually, it's in complete congruence with the seriousness displayed in the book this is sourced from. And yes, it's just as crazy as some discussions here. If you like those, you surely adore the book.
Mmm.
Well, the wikipedia disagrees, says the first version was 3/94.
No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins
And in <http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Versions> it clearly shows 3/94 as the first one, Slackware based, kernel 1.0
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlVhINUACgkQja8UbcUWM1xZQQEAmTpY2/P1tzO+9mCK1dXV9JEB WVx5WXRFFkfZJmVjvHoA/RBNA8kmbguNoJ+hLnKdTrTfSswrEf2jFfdPRf5FGuBO =2IVL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Sincerely, Bob Martens Webmaster/Technician Martin Luther College http://mlc-wels.edu -- This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. schrieb:
Well, the wikipedia disagrees, says the first version was 3/94.
No, it says 4.2 was the first under that name: http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Origins
And in <http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Versions> it clearly shows 3/94 as the first one, Slackware based, kernel 1.0
Sounds like that was basically just a German translation of Slackware, so I guess that's why people don't really count it as really the first S.u.S.E./SUSE releases. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-23 14:24, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
I would like the openSUSE numbers be the same or very similar to the SLES numbers of the release they base on. That would really mean something and be useful.
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known. /Per -- Per Jessen, Zürich (15.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 23 May 2015 20:48:10 +0200 Per Jessen wrote:
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.
I can confirm. No any idea of 42. (and I'm not interested in googling and so on). -- WBR Kyrill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-23 20:48, Per Jessen wrote:
Carlos E. R. wrote:
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.
I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhBkAACgkQja8UbcUWM1yhhgD+LK22apLeIFmPto7B++h74Fjp i1nN0U4ga5tcggKBMgYA/jSaFUmkJOM06jgHGU2ryRgEUi8QcFaHwpeilNY/CoFy =mlTX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/23/2015 06:59 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-05-23 20:48, Per Jessen wrote:
Carlos E. R. wrote:
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.
I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know.
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlVhBkAACgkQja8UbcUWM1yhhgD+LK22apLeIFmPto7B++h74Fjp i1nN0U4ga5tcggKBMgYA/jSaFUmkJOM06jgHGU2ryRgEUi8QcFaHwpeilNY/CoFy =mlTX -----END PGP SIGNATURE-----
Great book. Very entertaining movie. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, 23 May 2015 19:06:24 -0400 Roman Bysh <rbtc1@rogers.com> wrote:
On 05/23/2015 06:59 PM, Carlos E. R. wrote:
On 2015-05-23 20:48, Per Jessen wrote:
Carlos E. R. wrote:
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.
I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know.
Great book. Very entertaining movie.
And, first of all, possibly best of all, a great radio serial. Also TV serial. -- Graham Davis [Retired Fortran programmer - now a mere computer user] openSUSE Tumbleweed (64-bit); KDE 4.14.6; Kernel: 4.0.0; Processor: AMD Phenom II X2 550; Video: nVidia GeForce 210 (using nouveau driver); Sound: ATI SBx00 Azalia (Intel HDA) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-24 08:37, Graham P Davis wrote:
On Sat, 23 May 2015 19:06:24 -0400 Roman Bysh <> wrote:
On 05/23/2015 06:59 PM, Carlos E. R. wrote:
On 2015-05-23 20:48, Per Jessen wrote:
Carlos E. R. wrote:
I have no idea what the number 42 means.
And I suspect many people will agree with you. I know what it means, but while it's well-known in popular culture, I'm not sure it's universally known.
I know of the existence of some book called the hitchhiker guide to the galaxy, but I have never read it. That's about all I know.
Great book. Very entertaining movie.
And, first of all, possibly best of all, a great radio serial. Also TV serial.
Not in Spain. Totally unknown. It is only known is some parts of the world, and by certain people. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVhrqoACgkQtTMYHG2NR9VU6gCdG6z1mZyT0tJyFTYsurm70wam WtIAn37vTxgizy6NRqtKYHRYq2UCp1gg =rrKB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Not in Spain. Totally unknown.
It is only known is some parts of the world, and by certain people.
just google for: the answer to life the universe and everything -- Victor Pereira SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-26 22:48, Victor Pereira wrote:
Not in Spain. Totally unknown.
It is only known is some parts of the world, and by certain people.
just google for: the answer to life the universe and everything
I did that days ago. Having to google a joke spoils it. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVlOQMACgkQtTMYHG2NR9VcrQCfQJB3A98SIM01FG5e58vUFKXs +WIAnjVQ1iWxCsclLGcFl86wsvtkUJrX =pBkK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:
And, first of all, possibly best of all, a great radio serial. Also TV serial.
Not in Spain. Totally unknown.
I find that hard to believe, actually. You are not "all of Spain". There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole. And now you know about it. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 26/05/15 a las 23:10, Jim Henderson escibió:
On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:
And, first of all, possibly best of all, a great radio serial. Also TV serial.
Not in Spain. Totally unknown.
I find that hard to believe, actually. You are not "all of Spain".
There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole.
And now you know about it.
Jim
Not totally unkown in Spain. I'm from Spain and I hear about it, and many other Geekos in spanish IRC channel, and other bloggers... 42 is universal, and it's the answer of everything :-) - -- - ------------------- GPG Key: 0xC9B7E22A Aprende a proteger la privacidad de tu correo: https://emailselfdefense.fsf.org/es/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVZOVQAAoJEMx0Lo3Jt+Iq/GsP/jUMtUS3rRdWE3TrS34uDOhu +jbidWs2B1bkOqkiW+WK+glMeSiys21oxCeTF58yad897Pmb+qNHNKCq21X+FSzP 1+jPpQwjmn0z3UBrwlkmK7HiEB0WDvA7CHP55dC0Uq2pzZBVsGmMm0EgcQGYTGau xQl5qQkiR4tb6N8L3tQeBrk50/0daOqNeYL2UZVrwxyiehUzY/uhad+4EefF+Qur Q5r/6uJXkr61QejWEp/o2hiUDAjiKlm5iFjI8TPMnOTUTQdzeqQ0CT7kjATQNDfF 8k9KmYtoiqmy8w+N7RRUAQPTYzdCqcyX/wV9yvr0GjS5bA9gQw/O6FnW1vclyk5f I8+c/E74zezWxQcdxfKKrkTU+uSnfusv7ljAc93po/bZ5efRCVPRWH5Ze1SBIE/h i4O8Jqf7AFQv1VuZRFcL+YkXFFVPcA3KGmqZsRNyntfj6WrRimFzg++CgY+vJDTE 21cwnzS/IOfCe/4JLeiL7mKBujEp3wDxo1aCdbMyng+rRq4KdAe9zonlpuzD3Odq hEjCWTa+VseLULSI2Jjqzh8+eMeGOl9tVUMMyek9xCxI62JUZlIu3yULrt5v37Mo 04TR4fZDbnR8l0uxMIMa7MqvXoAmZZYZL7nzK6E5BcJ1/bh4/jyesefvLzwKF+zg By1e8XJ6j24MRYdq/EwG =vKnp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-05-26 23:27, victorhck wrote:
El 26/05/15 a las 23:10, Jim Henderson escibió:
On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:
I find that hard to believe, actually. You are not "all of Spain".
There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole.
Obviously :-)
And now you know about it.
I still do not know if it is about science fiction or politics.
Not totally unkown in Spain.
I'm from Spain and I hear about it, and many other Geekos in spanish IRC channel, and other bloggers...
Well, I asked my friends and they don't :-p -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 27.05.2015 um 05:28 schrieb Carlos E. R.:
I still do not know if it is about science fiction or politics. You schould watch this video to learn something about it. ;-)
https://www.youtube.com/watch?v=TpQfWLkKbhw Stefan -- www.invis-server.org Stefan Schäfer Ludwigstr. 1-3 63679 Schotten -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 27 May 2015 05:28:54 +0200, Carlos E. R. wrote:
On 2015-05-26 23:27, victorhck wrote:
El 26/05/15 a las 23:10, Jim Henderson escibió:
On Sun, 24 May 2015 12:57:48 +0200, Carlos E. R. wrote:
I find that hard to believe, actually. You are not "all of Spain".
There is a Spanish-language edition of the book, so "totally unknown" is just hyperbole.
Obviously :-)
And now you know about it.
I still do not know if it is about science fiction or politics.
Then you should read the book or listen to the radio series.
Not totally unkown in Spain.
I'm from Spain and I hear about it, and many other Geekos in spanish IRC channel, and other bloggers...
Well, I asked my friends and they don't :-p
Not exactly a representative sampling of the entire population of Spain. And a stupid thing to be arguing about, too. If we came up with a sequential series of numbers, there's be someone who "didn't get it" or "didn't like it". Version numbers are generally all about bikeshedding and not much else. Contribute something meaningful rather than a debate about what number we should use for the next release. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 27 May 2015 16:59:12 +0000 (UTC) Jim Henderson <hendersj@gmail.com> wrote:
I still do not know if it is about science fiction or politics.
Then you should read the book or listen to the radio series.
And here's how it all started: https://www.youtube.com/watch?v=VcZJgKcAw6k -- Graham Davis [Retired Fortran programmer - now a mere computer user] openSUSE Tumbleweed; KDE Plasma 5.3.1; Kernel: 4.0.4; Processor: AMD Phenom II X2 550; Video: nVidia GeForce 210 (using nouveau driver); Sound: ATI SBx00 Azalia (Intel HDA) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 18:59, Jim Henderson wrote:
On Wed, 27 May 2015 05:28:54 +0200, Carlos E. R. wrote:
And a stupid thing to be arguing about, too. If we came up with a sequential series of numbers, there's be someone who "didn't get it" or "didn't like it". Version numbers are generally all about bikeshedding and not much else. Contribute something meaningful rather than a debate about what number we should use for the next release.
I don't care much what number system is used, as long as it is decided on a vote, because the current scheme was decided by a vote. That's the main point. And yes, many people do not know what the number 42 stands for; do not assume that everybody has the same cultural background on Earth. That should have been explained in the proposal, and this part of the discussion would not have even started. You may think it is bikeshedding, but the current number scheme was agreed upon after much debate and a two phase vote. That decision can not be simply ignored. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmG80ACgkQtTMYHG2NR9U8iwCfVaW1m4hnhV52sEfJ5umY1c/5 migAnRYnIcOp8KGdeudKcSQyK5GbXrui =00eO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Carlos E. R. <carlos.e.r@opensuse.org> [05-27-15 15:37]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 18:59, Jim Henderson wrote:
On Wed, 27 May 2015 05:28:54 +0200, Carlos E. R. wrote:
And a stupid thing to be arguing about, too. If we came up with a sequential series of numbers, there's be someone who "didn't get it" or "didn't like it". Version numbers are generally all about bikeshedding and not much else. Contribute something meaningful rather than a debate about what number we should use for the next release.
I don't care much what number system is used, as long as it is decided on a vote, because the current scheme was decided by a vote. That's the main point.
And yes, many people do not know what the number 42 stands for; do not assume that everybody has the same cultural background on Earth. That should have been explained in the proposal, and this part of the discussion would not have even started.
You may think it is bikeshedding, but the current number scheme was agreed upon after much debate and a two phase vote. That decision can not be simply ignored.
iiuc, this portion of the thread is missing the point. The designation of "42" is a placeholder/temporary-identifying-mark/name-to-use-until-proven or anything it can be called *just* to identify a possible collection of applications until such time as future action can be determined. It doesn't need or have to be "voted" on as it doesn't exist as a distributed version, now or sometime in the future. It is more like you would call your new-born, baby, until you have decided upon a name. Much todo is being spent far from the intended direction. And no matter what it ends up being called, there will be many voices in disagreement and those will be the loudest. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 21:57, Patrick Shanahan wrote:
* Carlos E. R. <> [05-27-15 15:37]:
iiuc, this portion of the thread is missing the point. The designation of "42" is a placeholder/temporary-identifying-mark/name-to-use-until-proven or anything it can be called *just* to identify a possible collection of applications until such time as future action can be determined. It doesn't need or have to be "voted" on as it doesn't exist as a distributed version, now or sometime in the future.
If that is so, it is acceptable. But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmJrAACgkQtTMYHG2NR9VXrQCdEIePpHatzIzW9ibB33/spjH8 ABgAnRNgnlE2BsNZVZbLCzQvJjhh3fOD =Jm/p -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Carlos E. R. <carlos.e.r@opensuse.org> [05-27-15 16:22]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 21:57, Patrick Shanahan wrote:
* Carlos E. R. <> [05-27-15 15:37]:
iiuc, this portion of the thread is missing the point. The designation of "42" is a placeholder/temporary-identifying-mark/name-to-use-until-proven or anything it can be called *just* to identify a possible collection of applications until such time as future action can be determined. It doesn't need or have to be "voted" on as it doesn't exist as a distributed version, now or sometime in the future.
If that is so, it is acceptable.
But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable.
In the context it was presented, the "decided by ..." *is* acceptable as it means nothing other than a means to identify a ?project. Agree that when it is presented for distribution, the versioning scheme should be decided by committee/vote/coin-toss/or some agreed means even though that agreement *will* not satisfy the "loudest voices" :^) It is still just a project (or any other name for it, collection of works), not a distro, ie: project vs product. And still not worthy of argument. done/bye -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 22:44, Patrick Shanahan wrote:
* Carlos E. R. <> [05-27-15 16:22]:
But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable.
In the context it was presented, the "decided by ..." *is* acceptable as it means nothing other than a means to identify a ?project. Agree that when it is presented for distribution, the versioning scheme should be decided by committee/vote/coin-toss/or some agreed means even though that agreement *will* not satisfy the "loudest voices" :^) It is still just a project (or any other name for it, collection of works), not a distro, ie: project vs product. And still not worthy of argument. done/bye
If that is so, it is acceptable :-) But it is not what he said, or not what I understood... (and I have looked it up again to refresh my memory). - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmLacACgkQtTMYHG2NR9VAeACffPlFENCpcjHUJeF9XVzoxXIF 7WYAoJHx7IbigARUuShCboUB5dZDuoJ5 =bPoc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 21:57, Patrick Shanahan wrote:
* Carlos E. R. <> [05-27-15 15:37]:
iiuc, this portion of the thread is missing the point. The designation of "42" is a placeholder/temporary-identifying-mark/name-to-use-until-proven or anything it can be called *just* to identify a possible collection of applications until such time as future action can be determined. It doesn't need or have to be "voted" on as it doesn't exist as a distributed version, now or sometime in the future.
If that is so, it is acceptable.
But someone did say here that it was not going to be voted at all, but decided by "the people that do it". That is not acceptable.
So, shall we vote on each package's inclusion in the distro as well? Each version? This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote. We vote for the board. We don't vote on a versioning scheme. As Patrick said, I'm done/out here. You want to continue to nitpick and argue about it, find someone else to do it with. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-27 23:37, Jim Henderson wrote:
On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:
So, shall we vote on each package's inclusion in the distro as well? Each version?
I never said that. Don't place words on my mouth that are not mine.
This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote.
Yes, it was. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmOkIACgkQtTMYHG2NR9V+hwCglKd5d3d/xpCHiFwrQMOTjxcU UugAn1mIZ3INOnUPdJKBgFthAfTf9b9L =RfuL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 27 May 2015 23:42:29 +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2015-05-27 23:37, Jim Henderson wrote:
On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:
So, shall we vote on each package's inclusion in the distro as well? Each version?
I never said that. Don't place words on my mouth that are not mine.
I did not say that you did.
This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote.
Yes, it was.
Now you're just arguing for the sake of arguing. Like I said: I'm done. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK people, On 05/27/2015 05:42 PM, Carlos E. R. wrote:
On 2015-05-27 23:37, Jim Henderson wrote:
On Wed, 27 May 2015 22:18:57 +0200, Carlos E. R. wrote:
So, shall we vote on each package's inclusion in the distro as well? Each version?
I never said that. Don't place words on my mouth that are not mine.
This is stupid, Carlos. The vote you cite wasn't a membership vote, and it wasn't a binding vote.
Yes, it was.
Lets just say that a name/version discussion at some point, when there is a better defined direction, is probably prudent. However, as should be rather evident in the more technically oriented part of the thread, there is still no convergence on what is actually going to happen. There is of course also the possibility that no convergence will be achieved and then we have to figure out what that implies and how to move forward with that situation. For the most part the discussion has remained factual and focused on the issues that concern people w.r.t. the distribution, lets keep it that way. We should also acknowledge that there are voices in the community that are concerned about the naming and versioning of whatever is next and should not dismiss those concerns out of hand, even if the discussion about this topic may be a bit pre-mature. 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 iQEcBAEBAgAGBQJVZj8lAAoJEE4FgL32d2UkNz8H/jcMlvClPDJlD4H+VCZ03tVO 85UxwezZeCEpYLwbmCLOWfcJUriteh3ly73U0ffGt9n0Tt+BUxBxGUuR4UmmLM72 nQn/8c1dQltkNFAHjCa15UZS7XrDz1bxrkDM+B6BJjwxlrMucX+4yxFFX9G0XdD1 9RvFb4Vah+A+aIhlhBNQCwWVMBfzjvhHLc4NwFcpYQukrqoziFzOSZaWD5Qfqktk K7tEykFgrlJCmpmP/jzoF+GDLxUsVwlXHorhXO0LXLckqO1zFPfES0bFmXYlVGgJ 9H0m7ShqdqZGxEJEb0oP5DJSErCmEQZxz6NP7S5b0c1It8W7G4IBBzTkByekPzo= =yZNS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-28 00:03, Robert Schweikert wrote:
OK people,
Yes, it was.
Lets just say that a name/version discussion at some point, when there is a better defined direction, is probably prudent.
Agreed :-)
However, as should be rather evident in the more technically oriented part of the thread, there is still no convergence on what is actually going to happen. There is of course also the possibility that no convergence will be achieved and then we have to figure out what that implies and how to move forward with that situation. For the most part the discussion has remained factual and focused on the issues that concern people w.r.t. the distribution, lets keep it that way.
We should also acknowledge that there are voices in the community that are concerned about the naming and versioning of whatever is next and should not dismiss those concerns out of hand, even if the discussion about this topic may be a bit pre-mature.
Agreed. Thanks for the understanding :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVmQgsACgkQtTMYHG2NR9XEZgCfTyjOsqIekleDnwbXrxTffNYH AZgAn0vaFNOBFriuu0wqzWofwp44+6Hv =6Uvl -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 27 May 2015 18:03:17 -0400, Robert Schweikert wrote:
We should also acknowledge that there are voices in the community that are concerned about the naming and versioning of whatever is next and should not dismiss those concerns out of hand, even if the discussion about this topic may be a bit pre-mature.
I can live with that. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 27 of May 2015 18:03:17 Robert Schweikert wrote:
Lets just say that a name/version discussion at some point, when there is a better defined direction, is probably prudent.
However, as should be rather evident in the more technically oriented part of the thread, there is still no convergence on what is actually going to happen.
Exactly. If we don't end up with something to name/number, the whole discussion about name/number would become kind of pointless. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 23 mei 2015 14:43:55 schreef Carlos E. R.:
On 2015-05-23 14:24, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com>
wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
I would like the openSUSE numbers be the same or very similar to the SLES numbers of the release they base on. That would really mean something and be useful.
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
I have no idea what the number 42 means.
-- Cheers / Saludos,
Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) Google "42". Also, the first S.u.S.E. was 4.2 for the same reason your google search will explain :) -- Gertjan Lettink, a.k.a. Knurpht
Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-23 21:03, Knurpht - Gertjan Lettink wrote:
Op zaterdag 23 mei 2015 14:43:55 schreef Carlos E. R.:
I have no idea what the number 42 means.
Google "42". Also, the first S.u.S.E. was 4.2 for the same reason your google search will explain :)
That's what you'll tell all the people asking why openSUSE will be named that way? There will be many :-) Actually, the first SuSE was "3/94". - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhBZQACgkQja8UbcUWM1yuHQD7B8K+Bp/ddBRRzbpr4hNuczik ZTJXVZI/Hu37WGdYqDIBAJyxK+f/dy/gWmyBjkZdMUqJzTmnNw5b47/C6eVvqMcs =3JQN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Richard, On 05/23/2015 03:24 PM, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward Why? What is the reasoning behind those statements?
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)
2. It confuses users I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem. It will lead to questions from our users "Why the big change? What is the difference from 13.2 and before?" and these are *exactly* the kind of questions we want to have our users ask, so we can answer them with very clear messages about the change to the Regular Release, how it will now be based on SLE Sources, how it'll be more stable, with a new schedule, with a new way of being built.
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
The surprise factor is a good point, but I would expect this not to work for a second time in the future :) I would prefer people talking about how good openSUSE is and not why the new version is +30 from SLE.
4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1? Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)
As long as we clearly explain the logic and meaning (or lack thereof) behind the openSUSE version numbering scheme, I don't think we're limited in what we can do if an idea like this crops up again.
3 years ago there was a *big* discussion about changing versioning model and it was followed by a vote by members. Are we going to ask members this time? Did the board decide already? Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 May 2015 at 15:17, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
Hi Richard,
On 05/23/2015 03:24 PM, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)
Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..
The surprise factor is a good point, but I would expect this not to work for a second time in the future :) I would prefer people talking about how good openSUSE is and not why the new version is +30 from SLE.
Then lets focus the marketing on talking about how good openSUSE is.. that''s irrelevant to this discussion about version numbering though, unless you think one of the reasons openSUSE is good is because we used to increment the version numbers by 0.1 every 12 months ;)
3 years ago there was a *big* discussion about changing versioning model and it was followed by a vote by members. Are we going to ask members this time? Did the board decide already?
The project doesn't make every decision based on democratic votes. We want to encourage the approach of "Those who do, decide", leave the decisions to the people actually putting stuff together for the Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release. We've been discussing on this list for some weeks now about the new approach for creating openSUSE releases based on the newly available SLE sources. A side effect of that requires us to reconsider the version number. I think this is a very different circumstance from 3 years ago, so I don't think that precedent from the past should be followed. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/23/2015 04:36 PM, Richard Brown wrote:
On 23 May 2015 at 15:17, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
Hi Richard,
On 05/23/2015 03:24 PM, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward Why? What is the reasoning behind those statements?
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning) Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..
Thanks for the effort but not convincing: Factory never had a release version, just release branches. Tumbleweed was initially based on 12.x and then 13.x before turning into a full rolling distribution. It was never officially named "Tumbleweed 13.1". Date-based release numbers make sense for Tumbleweed, 42.1 does not.
The surprise factor is a good point, but I would expect this not to work for a second time in the future :) I would prefer people talking about how good openSUSE is and not why the new version is +30 from SLE. Then lets focus the marketing on talking about how good openSUSE is.. that''s irrelevant to this discussion about version numbering though, unless you think one of the reasons openSUSE is good is because we used to increment the version numbers by 0.1 every 12 months ;)
I don't and never said such a thing.
3 years ago there was a *big* discussion about changing versioning model and it was followed by a vote by members. Are we going to ask members this time? Did the board decide already? The project doesn't make every decision based on democratic votes. We want to encourage the approach of "Those who do, decide", leave the decisions to the people actually putting stuff together for the Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release.
It is unfortunate to categorize people as "those who work on next release" and "those who don't". We have people (members) working on this project according to their available free time and skills i.e. maintaining packages, working on translations, documentation etc. Yes, there are also people working on core stuff and development of next release, and we are very grateful for their work, but it is not fair to compare everyone to Stefan ;)
We've been discussing on this list for some weeks now about the new approach for creating openSUSE releases based on the newly available SLE sources. A side effect of that requires us to reconsider the version number. I think this is a very different circumstance from 3 years ago, so I don't think that precedent from the past should be followed.
Yes, discussion is taking place on the mailing lists. But how are the decisions reached? I would prefer to see a board statement (or board meeting minutes or a vote result) each time a crucial decision is reached. Best, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-05-23 16:42, Angelos Tzotsos wrote:
Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..
Thanks for the effort but not convincing: Factory never had a release version, just release branches. Tumbleweed was initially based on 12.x and then 13.x before turning into a full rolling distribution. It was never officially named "Tumbleweed 13.1". Date-based release numbers make sense for Tumbleweed, 42.1 does not.
Absolutely.
Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release. It is unfortunate to categorize people as "those who work on next release" and "those who don't".
Indeed. I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlVhCnYACgkQja8UbcUWM1zvUgD/SFYZObQVVH3ogcwtK0JGJSF9 ht0Sv9MRdGcs6aN17L8A/0fZI/ewm/LNYI1ZHu+06yHNcQvLEAwJnqAi88pFNtXd =sbSP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2015 07:17 PM, Carlos E. R. wrote:
On 2015-05-23 16:42, Angelos Tzotsos wrote:
Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..
Thanks for the effort but not convincing: Factory never had a release version, just release branches. Tumbleweed was initially based on 12.x and then 13.x before turning into a full rolling distribution. It was never officially named "Tumbleweed 13.1". Date-based release numbers make sense for Tumbleweed, 42.1 does not.
Absolutely.
Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release. It is unfortunate to categorize people as "those who work on next release" and "those who don't".
Indeed.
I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier.
Fair enough. However, would you not agree that a major change in the source base of the "regular" openSUSE release should be accompanied by a change in numbering? If we end up with a SLE source based regular release because those that do the release work decide that's the way to go should this not be called something different than 13.3? If the answer to those two questions is yes, then I would say it is fair to say that the starting point of a new version number is arbitrary. Thus, 42 is a good or bad as any number. 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 iQEcBAEBAgAGBQJVZHC+AAoJEE4FgL32d2UkAF4H/2Xv/EmU0MSsfCp2CPRaXroZ 6dzgVh1QSwj6xxZyxzlEOxtOnwP/rfwSEpENjGhSDwewh/TiriuPIUwAZbzYDKuu TpQKnO9kiZBrq0Zuy4kRzAiExzaYorkVM3mIqW1GaTLNOlXp0keHmPaW7lce3Flp gTZrjFodLrZRaboaj3/3qcoXk/OvwvOG/dZHHnoO0AyZXpOFjwKptdJ1th3/YZaD qCSoVKeloTHa5AGZjrabgHWA3/33+9aGWT3mYJ6MphAzZ+JDwTpCww2Gsm3ZWVKe a31MED8zAVw1urijfcOElCaZdY4rGNxoP0E/xCNXm8hR9snqIgTwbh98xsz8yzo= =/E6U -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-26 15:10, Robert Schweikert wrote:
On 05/23/2015 07:17 PM, Carlos E. R. wrote:
I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier.
Fair enough.
However, would you not agree that a major change in the source base of the "regular" openSUSE release should be accompanied by a change in numbering?
Perhaps.
If we end up with a SLE source based regular release because those that do the release work decide that's the way to go should this not be called something different than 13.3?
If the answer to those two questions is yes, then I would say it is fair to say that the starting point of a new version number is arbitrary. Thus, 42 is a good or bad as any number.
Perhaps. I don't oppose to call the new release "42", if that is what a vote decides. I don't like it, though, the number 42 doesn't mean anything to me (I had to read it up), so the pun, joke or whatever is lost on me. That guide to the galaxy thing is not universally known. Me, I would prefer a numbering system that clearly shows the SLES version the work is derived from. If it comes from SLES 12 SP 2, it would have to be something wit 12 2 in the name. However, I will accept any voted decision. That's my main point. :-) If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides? - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVkeA4ACgkQtTMYHG2NR9V2SwCglYJdkjDsv196QsgSfjYqx7yO TwgAn1LEnW6ZGlZ0yN+PLNk9V5I4MuMK =8fU9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 09:41 AM, Carlos E. R. wrote:
On 2015-05-26 15:10, Robert Schweikert wrote:
On 05/23/2015 07:17 PM, Carlos E. R. wrote:
I don't think such a decision should be left to a little group, even their work been fundamental. This was decided by a vote years ago, and a minority should not revoke a previous decision made by the majority some years earlier.
Fair enough.
However, would you not agree that a major change in the source base of the "regular" openSUSE release should be accompanied by a change in numbering?
Perhaps.
If we end up with a SLE source based regular release because those that do the release work decide that's the way to go should this not be called something different than 13.3?
If the answer to those two questions is yes, then I would say it is fair to say that the starting point of a new version number is arbitrary. Thus, 42 is a good or bad as any number.
Perhaps.
I don't oppose to call the new release "42", if that is what a vote decides.
I don't like it, though, the number 42 doesn't mean anything to me (I had to read it up), so the pun, joke or whatever is lost on me. That guide to the galaxy thing is not universally known.
Fair enough, but the number 13, that we have currently is equally arbitrary and meaningless. As stated elsewhere, and I paraphrase, version numbers are meaningless but necessary.
Me, I would prefer a numbering system that clearly shows the SLES version the work is derived from. If it comes from SLES 12 SP 2, it would have to be something wit 12 2 in the name.
But the dilemma is that we already had 12.2 and we can probably all agree that 13.2 -> 12.1 -> 12.2 -> 12.3/13.1 is probably not a good transition as it repeats very recent version numbers.
However, I will accept any voted decision. That's my main point. :-)
If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?
Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes. Every contributor has to decide for themselves whether they are going to submit the packages they maintain to the new project. Maybe the result is that the new thing is a lot smaller than our current releases. Who knows. Personally I have not yet come to terms with all of it. So far I have not heard one argument that would make me embrace the SLE source based release in the way that motivates me to do extra work. 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 iQEcBAEBAgAGBQJVZH1lAAoJEE4FgL32d2UkUEAIALvzEzosvTPsmvv23FLUod+o HyzBHHklP/HgXSsVKSJSCfBnm1uzYtoGa5m+NQTpCQTnv9h12WqfPaz4/gpcmXX2 thGWODFLRZx6K/jCRfCgh7pmAyok9g/PoFvMJFWba4hh0KG9vj5Zws9WDux7IwS8 3XRQUlWw40eWo+Lwa3Eov0XgGmQRHb4DvH4y/LiT43KOdSDgKR9PYx+KXvOrtpOM RneOgMSUd0Dg1cgU/ehafyj6ObuHrPw1W6ByhyQAMlXS5Ucty8ce0eWG0xtPdOzz q849ZnRNpNrFMWzh1qJ5BYuhh241y1y8y2QeRZ2baFDFx51yyF2yx3kvznsx3Z0= =d+/6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Robert Schweikert <rjschwei@suse.com> [2015-05-26 16:04]:
If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?
Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.
Every contributor has to decide for themselves whether they are going to submit the packages they maintain to the new project. Maybe the result is that the new thing is a lot smaller than our current releases. Who knows. Personally I have not yet come to terms with all of it. So far I have not heard one argument that would make me embrace the SLE source based release in the way that motivates me to do extra work.
I think this has an even bigger impact than that since this initiative has the potential to completely change the rules of the game. So far maintainers had to submit to and maintain packages in Factory where they were regularly branched into stable releases, that is Factory was the means to an end of having up-to-date packages in a stable release every 8 or 12 months. Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 10:40 AM, Guido Berhoerster wrote:
* Robert Schweikert <rjschwei@suse.com> [2015-05-26 16:04]:
If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?
Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.
Every contributor has to decide for themselves whether they are going to submit the packages they maintain to the new project. Maybe the result is that the new thing is a lot smaller than our current releases. Who knows. Personally I have not yet come to terms with all of it. So far I have not heard one argument that would make me embrace the SLE source based release in the way that motivates me to do extra work.
I think this has an even bigger impact than that since this initiative has the potential to completely change the rules of the game. So far maintainers had to submit to and maintain packages in Factory where they were regularly branched into stable releases, that is Factory was the means to an end of having up-to-date packages in a stable release every 8 or 12 months. Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
I agree. 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 iQEcBAEBAgAGBQJVZI/1AAoJEE4FgL32d2UkuvgH/2ENHYtwF3pvslX0m2xStNW0 9+ridQ84NiinU4LUd7heWRqtNkat4Twck7anpxC0Ml7eyNII7WaFWTw03UYSD704 UFaG0R2xpj0Tif6uoVEbmddHvldq354JsC05KggmTkYFfH2+d8mopcEXdqr17abg vxZUbewOg6JkDLrKXlkQIVhCGYTZVhM7Bx1Dcbc3fzTQr57OnDylXj9jPR9YiaQH D8f6pBKvQ5OYKekav+SFqzEbfW1lasYd6gQbIySW9NVWirF/apyIweRD+C6u07lF WqsD34uVSOwcm24OhiiNINfVIgrw4LPyQvBkkj/n1uU+hj+aP5LxScnN/N+gxSc= =qsz+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Die, 2015-05-26 at 16:40 +0200, Guido Berhoerster wrote:
I think this has an even bigger impact than that since this initiative has the potential to completely change the rules of the game. So far maintainers had to submit to and maintain packages in Factory where they were regularly branched into stable releases, that is Factory was the means to an end of having up-to-date packages in a stable release every 8 or 12 months. Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
Also, if that's how it turns out, doesn't that make the discussion about version numbers slightly moot? If the end product of basing a release on SLE turns out significantly differently than the factory-snapshot releases, is the version number the only degree of freedom in the naming scheme? For example, a release based on SLE 12 SP 2 might as well be called openSLE 12.2, in my opinion. The name emphasizes that its origins differ from those of other releases. As a side effect, it solves the conundrum of "reusing" openSUSE release versions. Don't get me wrong, I'm not against the idea as such. I find it an interesting approach that should be judged on its merits. Regards, Olav -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
So far maintainers had to submit to and maintain packages in Factory
Basically yes, but my understanding is that they should also maintain them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen. In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory. Regards, Christian Boltz [1] lots of things will break at once if you do this - which means a bigger pain than doing incremental updates -- Insgesamt denke ich, dass es einfacher ist, sich eine Pistole anzuschaffen und sich in den Fuß zu schiessen. Das Ergebnis ist das gleiche, aber wenigstens belästigst du nicht andere dabei. (^-^) [Sandy Drobic in postfixbuch-users über a-s-k.sourceforge.net] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 06:03 PM, Christian Boltz wrote:
Hello,
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
So far maintainers had to submit to and maintain packages in Factory
Basically yes, but my understanding is that they should also maintain them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)
Correct, but at release creation the package from factory ended up in the release. According to the current proposal this turns into an extra step. And we can all argue about whether or not this maintenance actually happened. One of the arguments for the SLE source based release is that the maintenance will actually happen while according to some it does not happen today.
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works. As it is proposed at present when someone sends a new package to factory the same package also has to be sent to :42 in order to be in the "regular" release. If I understand the original concern correctly, not getting stuff one contributes automatically into a "regular stable" release may deter people from contributing in the first place. 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 iQEcBAEBAgAGBQJVZPTAAAoJEE4FgL32d2Uk08UH/2UePGf/7HKy9mx0CQv2GPij Ees24Y7gwn+B8GJoAxlfC8mT21PWKXd3JV5A3DUSXp4SvrAkQ5VYtoYoDQwKAWn2 XHw/36SpdNIsfP/bS5MkseMQJpQsCYu7zOSIMuBYIx+biz/SmmDXndlH6pdxTPwq +dMH/SYSQW1y7z9NKQx6zDq4kqmIzbV2Syk09qoIAkehifYCLxr80IHNUtknP52V HaZKibHDdZJj9JdnFmYApMsjdQ8f/WfZVcSTWRTUHdY7yw80Jc+POdAmu2uVgMki 0m0Q8UimDNj3/xCzauAcHe3NIodCvJpeCJ6JC4wXQ7W4gPGNfXGQSl2v1oUr7J0= =rBUo -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 00:34]:
On 05/26/2015 06:03 PM, Christian Boltz wrote:
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.
Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above). -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Guido Berhoerster <gber@opensuse.org> Wed, 27 May 2015 10:40:34 +0300:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 00:34]:
On 05/26/2015 06:03 PM, Christian Boltz wrote:
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.
Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).
+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory. -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.05.2015 um 16:56 schrieb Dmitriy Perlow:
Guido Berhoerster <gber@opensuse.org> Wed, 27 May 2015 10:40:34 +0300:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 00:34]:
On 05/26/2015 06:03 PM, Christian Boltz wrote:
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.
Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).
+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory.
An interesting statement since I don't see any real difference between "openSLE" and openSUSE releases as of today. Does that mean that you also do not fix runtime issues of your packages for openSUSE 13.x? And if you do is it just because you use it? Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 12:57 PM, Wolfgang Rosenauer wrote:
Am 27.05.2015 um 16:56 schrieb Dmitriy Perlow:
Guido Berhoerster <gber@opensuse.org> Wed, 27 May 2015 10:40:34 +0300:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 00:34]:
On 05/26/2015 06:03 PM, Christian Boltz wrote:
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.
Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).
+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory.
An interesting statement since I don't see any real difference between "openSLE" and openSUSE releases as of today.
Well, the difference is that the openSUSE based on SLE model requires some extra effort and brings about some other complications, see Christian's comment regarding AppArmor, when compared to the current model. Current is simple, submit to Factory and the package will be in the next release. The "support" is relatively short and because the "regular" release doesn't get too old a version update in the "regular" release to fix a bug that is already fixed upstream is often possible, for a large part of the distribution. For :42 one has to create extra requests, one has to be prepared to support packages longer, and if newer versions of core packages are needed than those that come with "free maintenance" from SUSE one has to enter into negotiations with the maintainer of that package to override the package that comes from SLE. This of course creates extra work for the maintainer of the package one depends on. At this point a good number of contributors will probably ask themselves if it is worth the effort and additional time. Thus, the concern Guido expressed. 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 iQEcBAEBAgAGBQJVZf6+AAoJEE4FgL32d2UktkEH/jk5fSIXVSLLdpCFYRc0Mvfc zRTGkn0Udlebmxj89TY0kb+W5DdSqdyLsqo52+L9AsiLw7inPH4Oi/aIbN1wH/hl HVH8lTM8I7Q4pw7jXBJNPm0TxJ8G8x8tS4iczjBd0khAluZcWCo4v5jZdKb0TR7T uYPpxoM9m/mLuitvOrYrDSnvm2T626AnjkludIfWSUekgYf6TQBX5YWfaP0qqX9O lFmUjQqC3KsguHfgT8Mi/kLhvgFhaXz+ID6RnewGMwbO5jvDPWWHLpRlnm7P1QvF gOuN2bl8llqTYSwNxIt7BvLHPCEHVnbI+A9ol/noAsbu6DXEm8hsM3+KUWH2EgY= =Beux -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 May 2015 at 19:28, Robert Schweikert <rjschwei@suse.com> wrote:
For :42 one has to create extra requests, one has to be prepared to support packages longer, and if newer versions of core packages are needed than those that come with "free maintenance" from SUSE one has to enter into negotiations with the maintainer of that package to override the package that comes from SLE.
Where does this come from? Who said that in order for a newer version of a package to end up in openSUSE it will be required that an openSUSE contributor will need to 'enter into negotiations' with the SLE package maintainer? Sure, I hope that this whole exercise leads to more openSUSE contributors talking to more SLE engineers and visa versa, but I think you're grossly misrepresenting the nature of that collaboration with the way you present your argument here. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 01:47 PM, Richard Brown wrote:
On 27 May 2015 at 19:28, Robert Schweikert <rjschwei@suse.com> wrote:
For :42 one has to create extra requests, one has to be prepared to support packages longer, and if newer versions of core packages are needed than those that come with "free maintenance" from SUSE one has to enter into negotiations with the maintainer of that package to override the package that comes from SLE.
Where does this come from?
Just thinking through the issues people mentioned.
Who said that in order for a newer version of a package to end up in openSUSE it will be required that an openSUSE contributor will need to 'enter into negotiations' with the SLE package maintainer?
Well, Christian maintains AppArmor and as he pointed out the version in SLE is a bit behind. Thus, there are two options, the openSUSE based on SLE releases uses the "free maintained by SUSE" antiquated version of AppArmor or it get overridden by the package from Factory. And I did not say that the maintainer of the package has to negotiate with the SLE maintainer. One has to negotiate with the maintainer of a newer package one depends on. Which are two different things. Simple example. Before the fully automated maintenance of Perl modules I maintained perl-Readonly. For a while I deliberately held the version of the package back to keep it building and working on SLES 11 SP3. Now with the automated maintenance and because Readonly was getting quite long in the tooth we have the latest version in OBS. However, it no longer builds and works on SLES 11 SP3. Thus, if we had an openSUSE version based on SLES 11 SP3 sources I would have to negotiate with the Perl maintainer to update Perl in that version of openSUSE if in the next .x release the Perl version would not increase and a new version of perl-Readonly is desirable for our users. Yes, I know the counter argument is, "you are talking about something old". Well, SLE 12 will be old in just a few years and we will still be stuck with those sources as the base for openSUSE.
Sure, I hope that this whole exercise leads to more openSUSE contributors talking to more SLE engineers and visa versa, but I think you're grossly misrepresenting the nature of that collaboration with the way you present your argument here.
No comment to this last part 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 iQEcBAEBAgAGBQJVZgxSAAoJEE4FgL32d2UkUz0H/3QylDmgYZWhNCG4Xawe2qxt 77oNsa/ZowsSJ8oXUpvr3LahhYvRwLYb87Dyoz+ASl6PKKJ/VW5jzfEEXlsRR5oU R/k5mJ1Yc2vRaBQOiGf7h6cUwxLciZO7ASxGC3mBN9m6ghwI0x7VHtYwaU0x7KEu PfWMxe7Byjb+NVN9gynxwzJWZ4RL2Yo2jxySi7aZqxgUdLDbuYCWMTWtjteC6wvP TrCyo2o6zM1eVjbnvsMtAvjjY+u2a2VXPZVSCKzESphACcUr4Epq8/eCMDIsIfK8 yt6QQQTmYIVCd+FB9ZY44u6Odu61dvhxJuso5VoFY14oVxRCsRmZmdtKRXri3bQ= =Fx38 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Wolfgang Rosenauer <wolfgang@rosenauer.org> Wed, 27 May 2015 19:57:38 +0300:
Am 27.05.2015 um 16:56 schrieb Dmitriy Perlow:
Guido Berhoerster <gber@opensuse.org> Wed, 27 May 2015 10:40:34 +0300:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 00:34]:
On 05/26/2015 06:03 PM, Christian Boltz wrote:
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster:
Contributors who mainly use and deploy releases and are not be served very well by the outcome of the proposed model may well stop contributing to Factory too.
That could in theory happen.
In practise, you don't want to update your package only every 3 years IMHO [1], so I don't expect there will be many people who submit something only to the SLE-based releases, but not to factory.
It's the other way around. People will still submit to Factory, but may not submit to the openSUSE:42 project as this is no longer automagic when a new release is in the works.
Or do not contribute at all any more because neither Tumbleweed nor the openSUSE-SLE hybrid fits their use-cases any more (which was the point I was trying to make above).
+1. I'll not neither use «openSLE» nor fix runtime issues of my packages for both «openSLE» and openSUSE:Fatory.
An interesting statement since I don't see any real difference between "openSLE" and openSUSE releases as of today. Does that mean that you also do not fix runtime issues of your packages for openSUSE 13.x? And if you do is it just because you use it?
Wolfgang
I maintain all releases and Factory because I am interested in the next release. But if openSMTH is based on outdated SLE not Factory openSMTH will be useless for me because of old default (read as the only at OBS) compiler, X and other things. So what will be the reason to maintain useless releases basing on SLE and useless (since rolling doesn't suite me) Factory? -- Best regards, Dmitriy DA(P).DarkneSS Perlow @ Linux x64 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/27/2015 07:33 AM, Christian Boltz wrote:
Hello,
So far maintainers had to submit to and maintain packages in Factory Basically yes, but my understanding is that they should also maintain
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster: them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)
Hi all, My main concern with all this as the maintainer of enlightenment and co is that currently I rely on several packages that won't be in SLE core such as luajit and bullet physics so i'm left hoping that the existing maintainers of those packages will also feel like pushing to the new openSUSE release, as it would be a significant amount of extra effort for me to start tracking extra upstreams which could much better be spent working on enlightenment related packaging. I only have so much spare time around work family etc. Cheers Simon Lees - - - openSUSE Enlightenment Maintainer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 27 mai 2015 à 08:45 +0930, Simon Lees a écrit :
On 05/27/2015 07:33 AM, Christian Boltz wrote:
Hello,
So far maintainers had to submit to and maintain packages in Factory Basically yes, but my understanding is that they should also maintain
Am Dienstag, 26. Mai 2015 schrieb Guido Berhoerster: them in the releases if security issues or bugfixes warrant a maintenance update. (In other words: If you submit something to factory, you should also provide maintenance updates for supported openSUSE releases whenever needed.)
Hi all,
My main concern with all this as the maintainer of enlightenment and co is that currently I rely on several packages that won't be in SLE core such as luajit and bullet physics so i'm left hoping that the existing maintainers of those packages will also feel like pushing to the new openSUSE release, as it would be a significant amount of extra effort for me to start tracking extra upstreams which could much better be spent working on enlightenment related packaging. I only have so much spare time around work family etc.
Well, this will be mostly a "bootstrapping" issue for most major projects (GNOME:Factory has the same problem currently). I suggest you add a openSUSE:42 build target to your Devel project, to be able to easily track what is currently missing. And once coolo is back from vacations, some conversation will be needed on how to get the "packages missing from SLE source to oS:42". Once this initial bootstrap will be done, this extra work shouldn't be needed anymore.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-26 16:04, Robert Schweikert wrote:
On 05/26/2015 09:41 AM, Carlos E. R. wrote:
On 2015-05-26 15:10, Robert Schweikert wrote:
On 05/23/2015 07:17 PM, Carlos E. R. wrote:
Fair enough, but the number 13, that we have currently is equally arbitrary and meaningless. As stated elsewhere, and I paraphrase, version numbers are meaningless but necessary.
As long as whatever number or letter system is supported by a vote, I'll be happy. This is very different from saying that this or the other system is better.
If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?
Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.
There are other contributors that don't package or develop. Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVkicIACgkQtTMYHG2NR9UiQACeO5D50NZS33k+rgIg5HQWD7ts SDQAn3IqTL6qlghzmcTchvq3KDJSzSNc =Tk0b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 10:57 AM, Carlos E. R. wrote:
On 2015-05-26 16:04, Robert Schweikert wrote:
On 05/26/2015 09:41 AM, Carlos E. R. wrote:
On 2015-05-26 15:10, Robert Schweikert wrote:
On 05/23/2015 07:17 PM, Carlos E. R. wrote:
Fair enough, but the number 13, that we have currently is equally arbitrary and meaningless. As stated elsewhere, and I paraphrase, version numbers are meaningless but necessary.
As long as whatever number or letter system is supported by a vote, I'll be happy. This is very different from saying that this or the other system is better.
If "those who make it, decide", then I'm also a small contributor. I make a small part of it. Quite small. Where do we draw the line on who decides?
Yes, especially for the distribution the "those who do decide" paradigm has many corner cases. In the end everyone who maintains a package that is in factory contributes to the distribution. Only few contribute to the actual release work. Of course if snapshot based releases as "regular" releases get dropped, because those that do the actual release work want to release from another stream, that's fair enough. If the "regular" releases will be based on SLE sources and to get anything into this new release one has to submit additional requests, then the circle of "those who do" changes.
There are other contributors that don't package or develop.
Correct and those contributions matter as much as packaging and development.
Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us.
Well translating release notes for something that is called 13.3 or 42.1 should be about the same, taking the release notes as an example. Longer term the translation would potentially be more cyclic w.r.t. to the amount of translation needed. In a SLE-source based release idea there would be fewer changes between lets say 42.1, 42.2 than there will be 42.2 and 43.1 as within the 42 series changes to the "core" are expected to be very small while the transition to 43 would bring an "everything is new" distribution. Currently we get a ""everything is new" distribution with every "regular" release. 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 iQEcBAEBAgAGBQJVZI0pAAoJEE4FgL32d2Ukoj0H+gNFPsaMmjpd5QJSiq/HYRWg XnQUY2XCY0AEeAnrgldVutw+No5bcxpIqYNC1PqUnNmgsxWrThURP2Ebq1zCD0xD bvMKAdm5TkTNmVWeDDiIpApvshV+kAq6Y355DsnbWggyP80IP0wTcQXaYyVFuhyv WyNElKg6KgkE5/5F3TNKVVQZ4M0QqrZ5vNnyxNizfbSx39sQHtGxEExCw/UWoolf CB/AT2EdHmBNMvpKO927tXIVui+tM4bmduWTsfKxrklZSGrUVJoPZKPgVRwAkDc3 c6EkO3ToHN7EPlvTdHcVtjSxuA/mPIDT+by5nTa8B/M2jkq8puD4mHrs08J9NDQ= =JOxH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-26 17:11, Robert Schweikert wrote:
On 05/26/2015 10:57 AM, Carlos E. R. wrote:
There are other contributors that don't package or develop.
Correct and those contributions matter as much as packaging and development.
Thanks :-)
Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us.
Well translating release notes for something that is called 13.3 or 42.1 should be about the same, taking the release notes as an example. Longer term the translation would potentially be more cyclic w.r.t. to the amount of translation needed. In a SLE-source based release idea there would be fewer changes between lets say 42.1, 42.2 than there will be 42.2 and 43.1 as within the 42 series changes to the "core" are expected to be very small while the transition to 43 would bring an "everything is new" distribution. Currently we get a ""everything is new" distribution with every "regular" release.
Translating release notes is almost trivial :-) The problem is the translation of software. Currently we translate yast and zypper, and a number of programs for which openSUSE is upstream. We don't translate KDE, gnome, xfce, libreoffice, etc: that's done by their respective upstream projects. Now, SLES is translated, at least some core languages, by paid translators. Often those same programs are translated differently by the openSUSE volunteer translators. And we dedicate more time and effort and love to it than the paid translators, I'm proud to say. But with code ported from SLES, at least some of the openSUSE translators will be "out of a job". It is not clear at all what we will do. And no, we don't translate tumbleweed. Some individuals dedicate some time to it, but it is basically not done. We can't. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlVlOLoACgkQtTMYHG2NR9XKjwCfVmFNgRXROezKaR69HtOuCO7F 9OwAn0SZRx4x6J4RJP+09aY6m6PWzvLD =5qIa -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/26/2015 11:23 PM, Carlos E. R. wrote:
On 2015-05-26 17:11, Robert Schweikert wrote:
On 05/26/2015 10:57 AM, Carlos E. R. wrote:
There are other contributors that don't package or develop.
Correct and those contributions matter as much as packaging and development.
Thanks :-)
Me, for instance, I translate. And I have no idea what basing on SLES will suppose for us.
Well translating release notes for something that is called 13.3 or 42.1 should be about the same, taking the release notes as an example. Longer term the translation would potentially be more cyclic w.r.t. to the amount of translation needed. In a SLE-source based release idea there would be fewer changes between lets say 42.1, 42.2 than there will be 42.2 and 43.1 as within the 42 series changes to the "core" are expected to be very small while the transition to 43 would bring an "everything is new" distribution. Currently we get a ""everything is new" distribution with every "regular" release.
Translating release notes is almost trivial :-)
The problem is the translation of software. Currently we translate yast and zypper, and a number of programs for which openSUSE is upstream. We don't translate KDE, gnome, xfce, libreoffice, etc: that's done by their respective upstream projects.
Now, SLES is translated, at least some core languages, by paid translators. Often those same programs are translated differently by the openSUSE volunteer translators. And we dedicate more time and effort and love to it than the paid translators, I'm proud to say.
But with code ported from SLES, at least some of the openSUSE translators will be "out of a job".
It is not clear at all what we will do.
And no, we don't translate tumbleweed. Some individuals dedicate some time to it, but it is basically not done. We can't.
Makes sense. Well depending on what packagers decide they want to push into openSUSE based on SLE (openSUSE_EB EB == Enterprise Based) I am certain there will be stuff that needs translating. Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based). 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 iQEcBAEBAgAGBQJVZeUHAAoJEE4FgL32d2UkjTwIAMH64krUOp4IWkzCiAOmHLrw omvB8w2Dte/Z+Yd3/9oZTjrVJ56loRxwLjwn2MCmZQAMv3pTD8d/2m8+OpwGLDrJ c2GHwvsGj6PuOAVEHlycsK5U0zbnNF8Vqay+ejjRx1m7Frb8vWzUn53Letrfxgp+ fz329qFgX4NKPiCZWlaeOOUneIiyIitkR5+EXkHF+svxpH/OlkdlTRSjQp/m1079 ng9yGFoKA+hy8fzFwd8WwugCo1bAHkhzFb4lcuMhx2wPG8MewDOeB65siwrKu59T Lslby3o66cA7vSQcrssFCyuQZqPNbpfT7YLIAVqWBUzp3AUtedK458iWnXxYInU= =L4Xx -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 17:39]:
Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based).
I still don't get how this SLE base system is solving the "not enough people involved in release engineering" problem. Sure, it means less work for SUSE staff maintaining Ring 0/1 packages in both SLE and openSUSE, but will they all help with maintaining Factory and release engineering tasks? And with the currently proposed approach you effectively create two "Factories", openSUSE:42 and openSUSE:Factory which both require coordination and maintenance. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2015 04:54 PM, Guido Berhoerster wrote:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 17:39]:
Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based).
I still don't get how this SLE base system is solving the "not enough people involved in release engineering" problem.
It doesn't and it also does not solve some of the other problems we have, IMHO, as was pointed out during one of the general sessions at oSC15. A SLE source based openSUSE release is something else to build, another approach to create a distribution. In how far this approach may or may not be interesting is, IMHO, the basis for this discussion. My point is that if those few that get the distribution out the door today decide to no longer care for a Factory snapshot based distribution release, then maybe another team will form that will pick this back up. We just have to see how this develops. 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 iQEcBAEBAgAGBQJVZjkRAAoJEE4FgL32d2UkSX4H/jmt+3e0/en+YmK4kwR9a52B EtidDCCmyraIWJ/7+qMdEEyPhR2733e3783FIkFBWgk5bMumUuB8wlNC/pRLYpbE 6HNJ74N3nhJP0LjT9YHYqCKm1U8MF1pvp2myXDwBkvgIlnVpqWyVbtOI4llGd7wb XXVqEdag7OuTivJmDqGG/9QJsua8DPy1otDr9XztcBNjBD+IzNS2gQ/AFo439vZT e7+PZMCtdHbpGv7JgfPdT2o/mbeYdkN+T1h39Rgzy6B0Wq81mHX+dtWNClEfLSpm u61kQJvYbC7A0ZgWnjKjGanFCXEUYGp6PL97i265bMVcQrkdSIBova2lcU4e3tA= =idG0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Guido Berhoerster - 22:54 27.05.15 wrote:
* Robert Schweikert <rjschwei@suse.com> [2015-05-27 17:39]:
Also no one has declared snapshot releases as dead. Effectively we only have a very small number of people that end up doing the release work but maybe this is a sufficient enough disruption to motivate other people to do something else, maybe openSUSE_FB_1 (openSUSE Factory Based).
I still don't get how this SLE base system is solving the "not enough people involved in release engineering" problem. Sure, it means less work for SUSE staff maintaining Ring 0/1 packages in both SLE and openSUSE, but will they all help with maintaining Factory and release engineering tasks? And with the currently
Factory is doing better than regular release I would say. So this solution is supposed to scratch the itch that itches the most.
proposed approach you effectively create two "Factories", openSUSE:42 and openSUSE:Factory which both require coordination and maintenance.
Not really Factories as openSUSE:42 would move much slower and I would personally expect it to be even much smaller. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-05-23 15:36, Richard Brown wrote:
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)
Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million,
That exactly just sucks, because it is on the edge of comparison two different things, even though I reckon that the date _is_ used as version number. A better example would be systemd, which jumped from 44 to 183 because it synced with udev. The version bump was not involved in making systemd/udev a success, and since openSUSE cannot even bring the synchronization argument, that's the result.
The project doesn't make every decision based on democratic votes. We want to encourage the approach of "Those who do, decide", leave the decisions to the people actually putting stuff together for the Project, so I think the decision as to the version number of the next Regular Release should be left to those people who work on the creation of the next Regular Release.
It seems the definition of "working" seems to be limited to those doing OpenQA and ISO building. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt schrieb:
A better example would be systemd, which jumped from 44 to 183 because it synced with udev. The version bump was not involved in making systemd/udev a success, and since openSUSE cannot even bring the synchronization argument, that's the result.
When I was studying physics, one professor of Theoretical Physics had this sentence that he brought up again and again - "The coordinate system is both necessary and irrelevant at the same time." (It's necessary for creating mathematical descriptions, but it's not existent in nature and you can define it however you want, so it has to be scientifically irrelevant.) A few years ago, in the big discussions about the new Firefox versioning scheme, I realized the same is true for version "numbers" in software - they are both necessary and irrelevant. Necessary for orientation, to know by comparison if what you have is current, to know if what we talk about is the same state of code. Irrelevant as you can define your versioning scheme however you want. Doing 0.x forever, arbitrarily bump the major number when you feel like it (like the Linux kernel now), bump the major every development cycle (like Firefox), asymptotically nearing e or pi, having some large gaps, using 1 to 4 groups of digits, using years and months or plain numbers or even letters, start with 0 or 1, etc. - and that's all still within the boundaries of the common schemes - you can of course go even orthodox if you like, as long as there's some way to understand it. In the end, I found it healthy to think about it that way, removes a lot of "but this is wrong" (as there is no right or wrong - remember, they're as irrelevant as necessary) and replaces it with "is it useful, can we work with this reasonably?" instead. KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24.05.15 Robert Kaiser wrote:
In the end, I found it healthy to think about it that way, removes a lot of "but this is wrong" (as there is no right or wrong - remember, they're as irrelevant as necessary) and replaces it with "is it useful, can we work with this reasonably?" instead.
+1. Let's focus on what's inside the release, not how it is called... Johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlVh9BEACgkQzi3gQ/xETbIRdQCgh8AKt38qmqFg07HW8pQp/X1B 8gcAn0S/7vDVSFhNBK6sFlNVR8SnT4To =fHMt -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2015 09:36 AM, Richard Brown wrote:
On 23 May 2015 at 15:17, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
Hi Richard,
On 05/23/2015 03:24 PM, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way? Version numbers should at least have a continuation (if not other meaning)
Tumbleweed/Factory jumped from 13.1 to 20141104, a jump of 20 million, 141 thousand and ninety version numbers..and it turned out to be a success..
This is not really a good comparison or analogy. Tumbleweed/Factory is a different beast. 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 iQEcBAEBAgAGBQJVZG7nAAoJEE4FgL32d2UkXXoH/0bmis3AIOAsXB7jjfoRVvvd sV/iKJ7ztwS2jP37HZVEcTe0Nuqlxb3LrjonUlV9oL8P8UpKG3ayc6ctEiGL29yQ vgKIfDo2kO/SCvXNiRMabuVRQ6CjvzimZiFQcDT6aACtMMRLEUbNrIk/1322pXPO MzKdErk6uEww5aiq2XZ+cgaYXdoQ0+1DpVBwRnjiqThcrGHynYdqYqFG4jMMwHnG dzjqwIenfS/AIX6QjP16mc04GzFzrtoj6wrFCiOEhKdVGK+C6BkyRiLO9RuO+cpP PTdw3uPFJEn8hR5I31RqbTvtwV3aVQnfZr9KBqF1MuQtXcURwVW1FTY8+ZoVtjQ= =cNr6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 23.05.2015 um 15:17 schrieb Angelos Tzotsos:
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way?
Windows. Ok, they bumped 91.89 version numbers :-P
Version numbers should at least have a continuation (if not other meaning)
Why? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-05-23 19:40, Stefan Seyfried wrote:
Am 23.05.2015 um 15:17 schrieb Angelos Tzotsos:
Can you please point me to one example where a software project bumped ~30 version numbers and this turned out to be a success in any way?
Windows. Ok, they bumped 91.89 version numbers :-P
And then they went from 98 to 2000, and then to single-digits again (after a few named intermezzos). Sounds like a plan. RedHat knows that, too. They also moved from "RHL9" to "RHEL1", not touching 10. That was _smart_, too. Meaningful counting stops when a language has run out of unique words: in French, 17 is the first number whose word is built from previous numbers, in most West Germanic languages, it is 13, in Italic/Greek and many Asian ones, it is 11. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown schrieb:
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
And if it's released in Northern Hemisphere fall/autumn, it may just come with Firefox 42 out of the box! ;-) KaiRo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Saturday 2015-05-23 14:24, Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements? I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem.
Microsoft too once thought bumping version numbers bigtime is a good idea. By now, they ended up with (1, 2, 3, 95, 98, 2000, XP, Vista, 7), which messes with trivial sorting in all respectable ways, thanks to the switch from digits to letters and back again, and the breaking of strict ordering (7 > 2000?!). Please, let's learn something of that. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-05-24 10:20 (UTC+0200):
Microsoft too once thought bumping version numbers bigtime is a good idea. By now, they ended up with (1, 2, 3, 95, 98, 2000, XP, Vista, 7), which messes with trivial sorting in all respectable ways, thanks to the switch from digits to letters and back again, and the breaking of strict ordering (7 > 2000?!). Please, let's learn something of that.
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2015-05-24 11:08, Felix Miata wrote:
Jan Engelhardt composed on 2015-05-24 10:20 (UTC+0200):
Microsoft too once thought bumping version numbers bigtime is a good idea. By now, they ended up with (1, 2, 3, 95, 98, 2000, XP, Vista, 7), which messes with trivial sorting in all respectable ways, thanks to the switch from digits to letters and back again, and the breaking of strict ordering (7 > 2000?!). Please, let's learn something of that.
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm
And, where is the problem? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-05-24 11:15 (UTC+0200):
Felix Miata wrote:
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm
And, where is the problem?
Filename with version sorts do not match chronological sorts due to missing placeholders: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm should be Oct 22 2014 kernel-desktop-3.16.6-02.1.i686.rpm or maybe Oct 22 2014 kernel-desktop-3.16.602.1.i686.rpm and Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm should be Dec 21 06:54 kernel-desktop-3.16.7-07.1.i686.rpm or Dec 21 06:54 kernel-desktop-3.16.707.1.i686.rpm and Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm is OK or could be Apr 22 07:30 kernel-desktop-3.16.721.1.i686.rpm producing lists of equal digit counts like Oct 22 2014 kernel-desktop-3.16.6-02.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-07.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm and/or Oct 22 2014 kernel-desktop-3.16.602.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.707.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.721.1.i686.rpm -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2015-05-24 11:35, Felix Miata wrote:
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm
And, where is the problem?
Filename with version sorts do not match chronological sorts
You know what to do for these rpms: sort -V The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Jan Engelhardt composed on 2015-05-24 12:07 (UTC+0200):
Felix Miata wrote:
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm
And, where is the problem?
And instead of proceeding from 3.39 to 3.40 we got 4.0, 4.1, 4.2, etc. to get backwards again at 4.9 going to 4.10 in several months.
Filename with version sorts do not match chronological sorts
You know what to do for these rpms: sort -V
That's no help in a MC or FTP panel or after pasting a listing from a web browser into a spreadsheet. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24.05.2015 um 12:07 schrieb Jan Engelhardt:
The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7).
So what? They have an internal release number thats monotonically increasing and has not much to do with the marketing name. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 2015-05-24 13:53, Stefan Seyfried wrote:
Am 24.05.2015 um 12:07 schrieb Jan Engelhardt:
The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7).
So what? They have an internal release number thats monotonically increasing and has not much to do with the marketing name.
So what? SLE12 is known as %suse_version==1315, but does that help? The argument always was about the marketing name - it too is desired to be monotonically increasing for one and the same product row. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24.05.2015 um 14:05 schrieb Jan Engelhardt:
The argument always was about the marketing name - it too is desired to be monotonically increasing for one and the same product row.
By you. Not by me. I couldn't care less :-) And that's about all the discussions: Coolo just tries to bootstrap the new release version and because it does not have a name yet, he just names it "42". And instead of testing, fixing etc. people spend lots of time discussing the name. I would have actually expected the discussion to still go about "Really base on SLES12?", because I do not remember that an agreement had been reached, instead of about the name / version number jump. (Note that I don't complain about the "base it on SLES12" approach, not becaue I particularly like it, but becase *I* am not the one doing the work on this, and I heavily support the "those doing the work decide", even if it brinds us stuff I don't like). Best regards -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-05-24 15:44:05 +0200, Stefan Seyfried wrote:
(Note that I don't complain about the "base it on SLES12" approach, not becaue I particularly like it, but becase *I* am not the one doing the work on this, and I heavily support the "those doing the work decide", even if it brings us stuff I don't like).
+1 darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sunday 24 of May 2015 15:44:05 Stefan Seyfried wrote:
And that's about all the discussions: Coolo just tries to bootstrap the new release version and because it does not have a name yet, he just names it "42".
\o/ I was already starting to fear that nobody is going to notice this "42" is only a working title, not a definitive version number. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05/24/2015 07:37 PM, Jan Engelhardt wrote:
On Sunday 2015-05-24 11:35, Felix Miata wrote:
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm And, where is the problem? Filename with version sorts do not match chronological sorts You know what to do for these rpms: sort -V
The problem I was talking about is that *NEITHER* sort, nor sort -n/-g, nor sort -V would sort (98,XP,7) as (98,XP,7). For this reason there is a pretty sane version number scheme behind the marketing crap that developers can use to figure out which version there running https://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Sun, 24 May 2015 05:35:10 -0400 Felix Miata <mrmazda@earthlink.net> пишет:
Jan Engelhardt composed on 2015-05-24 11:15 (UTC+0200):
Felix Miata wrote:
It's far too late for that in FOSS, e.g.: Oct 22 2014 kernel-desktop-3.16.6-2.1.i686.rpm Apr 22 07:30 kernel-desktop-3.16.7-21.1.i686.rpm Dec 21 06:54 kernel-desktop-3.16.7-7.1.i686.rpm
And, where is the problem?
Filename with version sorts do not match chronological sorts due to missing placeholders:
ls -v -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It is sad to see that interesting thread was stolen by some absolutely irrelevan discussion about numbers. I still have some qeustions about how will it work exactly, hopefully Richard or someone else from the merging initiative will be able to answer it: 1. In context of SLE, what does SP1 means? Does it include only backports of fixes, or does it include version bump as well? Which effectively means, will the core of openSUSE N+0.1 be version updated with the release of SLE SP N+1 or will it stay the same? Good example will be higher Qt5 version requirement for plasma5. 2. How the important updates of core packages will be handled? Good example is recent release of GCC 5, it exposed lots of issues in different pieces of software, but lots of people would like to establish it for some reason. I would assume that the change will not go to SP in SLE, maybe only to next major version. Does it mean the same for openSUSE, or will openSUSE be used as a playground/nightly for SLE to get rid of all possible transition issues before the release of SLE? 3. Will it be possible to have different repos for core of the system (not sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the system? With some previous releases of openSUSE adding updated KDE repositories allowed the unholy mix of official/updated versions if there were any package name changes, which became obvious only much later. Would be great to have built-in defence against such cases by making it just separate repository. On Saturday 23 May 2015 14:24:46 Richard Brown wrote:
On 23 May 2015 at 14:06, Angelos Tzotsos <gcpp.kalxas@gmail.com> wrote:
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 3. It is awkward
Why? What is the reasoning behind those statements?
2. It confuses users
I actually see any confusion caused by the big change in version numbering as an opportunity, not a problem. It will lead to questions from our users "Why the big change? What is the difference from 13.2 and before?" and these are *exactly* the kind of questions we want to have our users ask, so we can answer them with very clear messages about the change to the Regular Release, how it will now be based on SLE Sources, how it'll be more stable, with a new schedule, with a new way of being built.
I therefore think calling the next release openSUSE 42 or 42.1 is both very good for 'marketing' in general and our users specifically, it'll get their attention and we just need to make sure we also support this with clear, concise information about the nature of the Regular Releases in the future.
4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1?
Sure, why not? openSUSE version numbers have always been a work of meaningless fiction (eg. in the Old Model, numbers would change totally arbitrarily and have no meaning behind them at all openSUSE 12.3 -> 13.1 was not a 'major release', we could have called it openSUSE)
As long as we clearly explain the logic and meaning (or lack thereof) behind the openSUSE version numbering scheme, I don't think we're limited in what we can do if an idea like this crops up again.
-- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit :
It is sad to see that interesting thread was stolen by some absolutely irrelevan discussion about numbers. I still have some qeustions about how will it work exactly, hopefully Richard or someone else from the merging initiative will be able to answer it:
1. In context of SLE, what does SP1 means? Does it include only backports of fixes, or does it include version bump as well? Which effectively means, will the core of openSUSE N+0.1 be version updated with the release of SLE SP N+1 or will it stay the same? Good example will be higher Qt5 version requirement for plasma5.
With my SLE Desktop release manager hat: - usually during a service pack, we try to only backport fixes but for some particular features request, we might do a version bump, usually because the feature we need can't be backported easily or the resulting package would be too difficult to maintain - during SLE12, for service pack, we might be a bit more flexible regarding version bump for some components (compared to SLE11) - so far, for SP1, there is no plan for big version bump (mostly because SP1 will try to stabilize even further SLE12 GA). Regarding Qt5, we don't have plan to do a major version bump for SP1 (because we don't have a need for it, feature wise) but doing a version bump in SP2 is kind of expected. oh, and please, don't take those comments as "everything is set in stone" ;)
2. How the important updates of core packages will be handled? Good example is recent release of GCC 5, it exposed lots of issues in different pieces of software, but lots of people would like to establish it for some reason. I would assume that the change will not go to SP in SLE, maybe only to next major version. Does it mean the same for openSUSE, or will openSUSE be used as a playground/nightly for SLE to get rid of all possible transition issues before the release of SLE?
For gcc, this is different, because this will be a "toolchain" module for SLE customers (think of it as some additional repository) which will be in place and will update gcc stack on yearly basis, independent of the service pack. This is to allow customers who need a more recent gcc to get one, without replacing the "system" gcc. SLE people are not recompiling and shipping the SLE codebase with the new gcc major version, because it might add new bugs and I'm not sure it would be a good idea to do this on openSUSE, since openSUSE would loose part of the stability gained by reusing SLE codebase at its core. For smoothing transitions caused by a new gcc, I think TW is more appropriate.
3. Will it be possible to have different repos for core of the system (not sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the system? With some previous releases of openSUSE adding updated KDE repositories allowed the unholy mix of official/updated versions if there were any package name changes, which became obvious only much later. Would be great to have built-in defence against such cases by making it just separate repository.
I guess it will be a matter of the various projects maintainers, not really "openSUSE:42" itself.. -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Frederic,
Thanx for the responses. Some follow-up questions below...
On Wednesday 27 May 2015 13:17:05 Frederic Crozat wrote:
> Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit :
> > 1. In context of SLE, what does SP1 means? Does it include only backports
> > of fixes, or does it include version bump as well? Which effectively
> > means, will the core of openSUSE N+0.1 be version updated with the
> > release of SLE SP N+1 or will it stay the same? Good example will be
> > higher Qt5 version requirement for plasma5.
> With my SLE Desktop release manager hat:
> - usually during a service pack, we try to only backport fixes but for
> some particular features request, we might do a version bump, usually
> because the feature we need can't be backported easily or the resulting
> package would be too difficult to maintain
> - during SLE12, for service pack, we might be a bit more flexible
> regarding version bump for some components (compared to SLE11)
> - so far, for SP1, there is no plan for big version bump (mostly because
> SP1 will try to stabilize even further SLE12 GA).
>
> Regarding Qt5, we don't have plan to do a major version bump for SP1
> (because we don't have a need for it, feature wise) but doing a version
> bump in SP2 is kind of expected.
>
> oh, and please, don't take those comments as "everything is set in
> stone" ;)
That makes sense. But that means that the gap between SLE and openSUSE will
increase with number of SPs, increasing efforts for both parties, or is there
some plan to keep sharing the effort in preparation for next major SLE
release?
> > 2. How the important updates of core packages will be handled? Good
> > example is recent release of GCC 5, it exposed lots of issues in
> > different pieces of software, but lots of people would like to establish
> > it for some reason. I would assume that the change will not go to SP in
> > SLE, maybe only to next major version. Does it mean the same for
> > openSUSE, or will openSUSE be used as a playground/nightly for SLE to get
> > rid of all possible transition issues before the release of SLE?
> For gcc, this is different, because this will be a "toolchain" module
> for SLE customers (think of it as some additional repository) which will
> be in place and will update gcc stack on yearly basis, independent of
> the service pack. This is to allow customers who need a more recent gcc
> to get one, without replacing the "system" gcc.
>
> SLE people are not recompiling and shipping the SLE codebase with the
> new gcc major version, because it might add new bugs and I'm not sure it
> would be a good idea to do this on openSUSE, since openSUSE would loose
> part of the stability gained by reusing SLE codebase at its core.
>
> For smoothing transitions caused by a new gcc, I think TW is more
> appropriate.
Looking at packaging and buildservice mailing lists, looks like there are some
issues when people are trying to use non-default gcc version for their
projects. How do you think, will that be resolved, or will newer version of
(for example) gcc be provided only for developers working on SLE/openSUSE and
not for OBS-built packages?
> > 3. Will it be possible to have different repos for core of the system (not
> > sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the
> > system? With some previous releases of openSUSE adding updated KDE
> > repositories allowed the unholy mix of official/updated versions if there
> > were any package name changes, which became obvious only much later.
> > Would be great to have built-in defence against such cases by making it
> > just separate repository.
>
> I guess it will be a matter of the various projects maintainers, not
> really "openSUSE:42" itself..
Ah, ok, this distinction is not yet clear to me.
--
Regards,
Stas
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.05.2015 um 13:59 schrieb Stanislav Baiduzhyi:
That makes sense. But that means that the gap between SLE and openSUSE will increase with number of SPs, increasing efforts for both parties, or is there some plan to keep sharing the effort in preparation for next major SLE release?
Why would the gap increase with SLE SPs? My understanding (which might also be wrong and stand corrected): SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning. Wolfgang (*) let me just call it 42 here to make sure it's clear what I mean -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 27 May 2015 14:07:33 Wolfgang Rosenauer wrote:
Am 27.05.2015 um 13:59 schrieb Stanislav Baiduzhyi:
That makes sense. But that means that the gap between SLE and openSUSE will increase with number of SPs, increasing efforts for both parties, or is there some plan to keep sharing the effort in preparation for next major SLE release?
Why would the gap increase with SLE SPs?
My understanding (which might also be wrong and stand corrected):
SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning.
Hm, that's right, I forgot to ask: what will be the goal of +0.1 releases of openSUSE? Will it be upgrade of WM/DE/apps on top of the same stable core of SLE, or some Ring 0/1 parts minght be affected as well? I would expect the gap increase for latter. -- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 May 2015 at 14:24, Stanislav Baiduzhyi <baiduzhyi.devel@gmail.com> wrote:
Hm, that's right, I forgot to ask: what will be the goal of +0.1 releases of openSUSE? Will it be upgrade of WM/DE/apps on top of the same stable core of SLE, or some Ring 0/1 parts minght be affected as well? I would expect the gap increase for latter.
--
The 'goal' is a tough one to answer - if you haven't gathered from from Frederics answer, this is also a topic of some debate within SUSE when it comes to their Service Packs I guess it's easier to talk about it in terms of 'opportunities' and 'expectations' So, for SLE Service Packs, I would describe the expectations from SLE customers is that each SLE service pack will be 1) Easy to upgrade to 2) Compatible with everything they're running on top of the current Service Pack. 3) Include Fixes and Hardware enablement 4) Also include new features (either as backports, or as new versions, see #5) 5) Might also include new versions of stuff. And when I say 'stuff', I mean both 'userland' (DE/WM/apps stuff) and 'kernel-land' stuff, but still maintaining the compatibility expectation in #2. So for SLE ,the 'goal' is to fulfil those expectations with each service pack. For SLE 12 SP1, the current focus for SUSE seems to be on numbers 1-4. SLE 12 SP2 is likely to also include #5. For openSUSE minor releases (based on those SLE Service Packs) I think those 'SLE Customer' expectations pretty much mirror what openSUSE user expectations will be for each minor release. So I would propose we think along the same lines for each openSUSE minor release. However, the most contentious one seems to be around #5 - I think it's fair to say that some of our openSUSE users may wish new versions of stuff faster than SLE users expect it. (However, this is also getting a more diverse situation, with SLE customers having 'Modules' and the newly announced Backports project, both of which enable newer versions of stuff ontop of their SLE installations but with a lower support expectation) And so, here's where I think openSUSE has opportunities. openSUSE has these SLE sources as a starting point. Somewhere for us to build from, and extend upon. If *we*, the community, decide to include more 'new stuff' in our minor versions, we can, and sometimes I think we should. But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway. Or to put it sufficiently, we have the opportunity to have the 'best of both worlds' with this approach, but exactly where that line is depends primarily on the work our maintainers are willing to do, the packages they submit, and the maintenance they're prepared to do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I’d like to shout “here, here” in response to Richard’s posts. It mirrors my own thoughts on the entire “let’s use SLE-sources to make something awesome” debate. Sincerely, Bob Martens Martin Luther College Webmaster/Technician http://mlc-wels.edu
On May 27, 2015, at 8:18 AM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 27 May 2015 at 14:24, Stanislav Baiduzhyi <baiduzhyi.devel@gmail.com> wrote:
Hm, that's right, I forgot to ask: what will be the goal of +0.1 releases of openSUSE? Will it be upgrade of WM/DE/apps on top of the same stable core of SLE, or some Ring 0/1 parts minght be affected as well? I would expect the gap increase for latter.
--
The 'goal' is a tough one to answer - if you haven't gathered from from Frederics answer, this is also a topic of some debate within SUSE when it comes to their Service Packs
I guess it's easier to talk about it in terms of 'opportunities' and 'expectations'
So, for SLE Service Packs, I would describe the expectations from SLE customers is that each SLE service pack will be 1) Easy to upgrade to 2) Compatible with everything they're running on top of the current Service Pack. 3) Include Fixes and Hardware enablement 4) Also include new features (either as backports, or as new versions, see #5) 5) Might also include new versions of stuff. And when I say 'stuff', I mean both 'userland' (DE/WM/apps stuff) and 'kernel-land' stuff, but still maintaining the compatibility expectation in #2.
So for SLE ,the 'goal' is to fulfil those expectations with each service pack.
For SLE 12 SP1, the current focus for SUSE seems to be on numbers 1-4. SLE 12 SP2 is likely to also include #5.
For openSUSE minor releases (based on those SLE Service Packs) I think those 'SLE Customer' expectations pretty much mirror what openSUSE user expectations will be for each minor release. So I would propose we think along the same lines for each openSUSE minor release.
However, the most contentious one seems to be around #5 - I think it's fair to say that some of our openSUSE users may wish new versions of stuff faster than SLE users expect it. (However, this is also getting a more diverse situation, with SLE customers having 'Modules' and the newly announced Backports project, both of which enable newer versions of stuff ontop of their SLE installations but with a lower support expectation)
And so, here's where I think openSUSE has opportunities. openSUSE has these SLE sources as a starting point. Somewhere for us to build from, and extend upon. If *we*, the community, decide to include more 'new stuff' in our minor versions, we can, and sometimes I think we should.
But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway.
Or to put it sufficiently, we have the opportunity to have the 'best of both worlds' with this approach, but exactly where that line is depends primarily on the work our maintainers are willing to do, the packages they submit, and the maintenance they're prepared to do. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 May 2015 at 15:18, Richard Brown <RBrownCCB@opensuse.org> wrote:
But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway.
A little addition/addendum to this paragraph Obviously, this situation is a little different for parts of openSUSE which are not present inside SLE, eg. KDE and all the other DE's besides GNOME. In those cases, we don't have the SLE version and it's 'free' maintenance as a fallback, but I think the general philosophy as to what we include stays the same. Our maintainers have the opportunity to decide what they put in each openSUSE minor release If they want to upgrade their packages in every minor release, I think that's certainly an option, but I would hope they do so in a way that is aligned with the general expectations our users are likely to have.. ie. that it's easy to upgrade to, and that it's broadly compatible with what they had in the last minor release. Part of me is re-reading that paragraph I just wrote and realise that it is actually quite silly to read.. of course we only want to provide upgrades that work, we're openSUSE, but hey, hopefully you will all forgive my stating the obvious and get the point I'm trying to get across. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 27 May 2015 15:45:20 Richard Brown wrote:
On 27 May 2015 at 15:18, Richard Brown <RBrownCCB@opensuse.org> wrote:
But, it comes with some costs or downsides. The most obvious downside to that is, every time we 'overwrite' something from the SLE sources with something newer for openSUSE, we have to be prepared to maintain that version for as long as we keep it in our supported versions of the distribution. With the new release model suggesting Major versions will be supported for 'at least 3 years', that's potentially a long time for people to be dedicated maintaining that. If our teams are willing to do it, great, let's do it. If not, then we have the opportunity to use the versions SUSE already provide and will be maintaining for SLE customers anyway.
A little addition/addendum to this paragraph
Obviously, this situation is a little different for parts of openSUSE which are not present inside SLE, eg. KDE and all the other DE's besides GNOME.
In those cases, we don't have the SLE version and it's 'free' maintenance as a fallback, but I think the general philosophy as to what we include stays the same. Our maintainers have the opportunity to decide what they put in each openSUSE minor release
If they want to upgrade their packages in every minor release, I think that's certainly an option, but I would hope they do so in a way that is aligned with the general expectations our users are likely to have.. ie. that it's easy to upgrade to, and that it's broadly compatible with what they had in the last minor release.
Part of me is re-reading that paragraph I just wrote and realise that it is actually quite silly to read.. of course we only want to provide upgrades that work, we're openSUSE, but hey, hopefully you will all forgive my stating the obvious and get the point I'm trying to get across.
Thanx for such a wide and informative response, it's much clearer now. The only question that remains: where is the schedule or roadmap, and cool clunter on the main page? :) -- Regards, Stas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 27 mei 2015 14:07:33 schreef Wolfgang Rosenauer:
My understanding (which might also be wrong and stand corrected):
SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning.
Wolfgang
That's exactly what I understood. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 May 2015 at 14:07, Wolfgang Rosenauer <wolfgang@rosenauer.org> wrote:
Why would the gap increase with SLE SPs?
My understanding (which might also be wrong and stand corrected):
SLE SP changes will be inherited into openSUSE 42(*) and probably result in 42.2 for SP2, 42.3 for SP3 and so on where minor releases are really minor releases in future where people should be able to safely upgrade to. The next major SLE (and openSUSE ?43?) would be based on Factory/Tumbleweed again and we start from the beginning.
Wolfgang
+1 - This is exactly how I would also expect things to work out -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mercredi 27 mai 2015 à 13:59 +0200, Stanislav Baiduzhyi a écrit : > Frederic, > > Thanx for the responses. Some follow-up questions below... > > On Wednesday 27 May 2015 13:17:05 Frederic Crozat wrote: > > Le mercredi 27 mai 2015 à 12:58 +0200, Stanislav Baiduzhyi a écrit : > > > 1. In context of SLE, what does SP1 means? Does it include only backports > > > of fixes, or does it include version bump as well? Which effectively > > > means, will the core of openSUSE N+0.1 be version updated with the > > > release of SLE SP N+1 or will it stay the same? Good example will be > > > higher Qt5 version requirement for plasma5. > > With my SLE Desktop release manager hat: > > - usually during a service pack, we try to only backport fixes but for > > some particular features request, we might do a version bump, usually > > because the feature we need can't be backported easily or the resulting > > package would be too difficult to maintain > > - during SLE12, for service pack, we might be a bit more flexible > > regarding version bump for some components (compared to SLE11) > > - so far, for SP1, there is no plan for big version bump (mostly because > > SP1 will try to stabilize even further SLE12 GA). > > > > Regarding Qt5, we don't have plan to do a major version bump for SP1 > > (because we don't have a need for it, feature wise) but doing a version > > bump in SP2 is kind of expected. > > > > oh, and please, don't take those comments as "everything is set in > > stone" ;) > > That makes sense. But that means that the gap between SLE and openSUSE will > increase with number of SPs, increasing efforts for both parties, or is there > some plan to keep sharing the effort in preparation for next major SLE > release? As Wolfgang mentioned in his reply, the preparation work for next major SLE (and therefore, next major openSUSE based on next SLE) should happen in Factory/Tumbleweed. > > > 2. How the important updates of core packages will be handled? Good > > > example is recent release of GCC 5, it exposed lots of issues in > > > different pieces of software, but lots of people would like to establish > > > it for some reason. I would assume that the change will not go to SP in > > > SLE, maybe only to next major version. Does it mean the same for > > > openSUSE, or will openSUSE be used as a playground/nightly for SLE to get > > > rid of all possible transition issues before the release of SLE? > > For gcc, this is different, because this will be a "toolchain" module > > for SLE customers (think of it as some additional repository) which will > > be in place and will update gcc stack on yearly basis, independent of > > the service pack. This is to allow customers who need a more recent gcc > > to get one, without replacing the "system" gcc. > > > > SLE people are not recompiling and shipping the SLE codebase with the > > new gcc major version, because it might add new bugs and I'm not sure it > > would be a good idea to do this on openSUSE, since openSUSE would loose > > part of the stability gained by reusing SLE codebase at its core. > > > > For smoothing transitions caused by a new gcc, I think TW is more > > appropriate. > > Looking at packaging and buildservice mailing lists, looks like there are some > issues when people are trying to use non-default gcc version for their > projects. How do you think, will that be resolved, or will newer version of > (for example) gcc be provided only for developers working on SLE/openSUSE and > not for OBS-built packages? IIRC, this is already the case in Factory, when a new gcc version is added in parallel but is not switched as the "default" compiler. Then there are staging project to rebuild the entire distro and when it is working fine, the switch is made. Maybe we could do that for oS:42 but I'm not sure it is worth the trouble to ship two compilers version. People who will want a more recent compiler version could grab it from OBS. (but I don't have a strong opinion on that topic ;) > > > 3. Will it be possible to have different repos for core of the system (not > > > sure if that's what Ring 0 and Ring 1 stands for) and other pieces of the > > > system? With some previous releases of openSUSE adding updated KDE > > > repositories allowed the unholy mix of official/updated versions if there > > > were any package name changes, which became obvious only much later. > > > Would be great to have built-in defence against such cases by making it > > > just separate repository. > > > > I guess it will be a matter of the various projects maintainers, not > > really "openSUSE:42" itself.. > > Ah, ok, this distinction is not yet clear to me. Just for completeness: the Rings (0 and 1) are small subsets of the packages (you might want to call them "core") which are used to stage the various new submissions for the distribution (so OBS don't have to rebuild the entire distribution for each new submission) and then, are used for openQA tests. They aren't really designed to act as a "minimal" installable distro (at least, ring 0 isn't, ring 1 could be seen as a minimal installable distro) but more as a partition of the package sets in the distribution, to help build and automated testing. I'm not sure it is a good idea to try to split the distro itself (ie as installation targets) in separate repositories, which could be selected or not, replaced or net, depending if you want a more up to date KDE (or GNOME, or whatever). Having additional repositories like it was done for GNOME in the past is probably easier to handle, since the choice is only in the hands of the respective project maintainer (openSUSE GNOME team in my example) and not the maintainers of oS:42. I hope my explanation is more clear but I'm not even sure myself after re-reading it twice ;) -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il 23/05/2015 14:06, Angelos Tzotsos ha scritto:
On 05/22/2015 03:23 PM, Stephan Kulow wrote:
A word on the version: openSUSE:42 is basically the working title of this parallel code stream mixing SLE12 and openSUSE sources. But we would release snapshots of this as openSUSE releases, I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
I would strongly suggest not to make such a version jump: 1. It is bad for marketing 2. It confuses users 3. It is awkward 4. It blocks us from another major version decision in the future i.e. what will be the version when something similar happens: openSUSE 154.1? +1
Please not, we don't need a big number syndrome. Daniele. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 22 May 2015 14:23:16 +0200, Stephan Kulow wrote:
I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
Not to bikeshed, but personally, I like it. Notwithstanding the Hitchhiker's Guide reference, but the history of the numbers "42" in the SUSE world - SUSE Linux 4.2 being the first release, YaST's first version being 0.42 (which were, as I understand it, references to "The Answer"). Given this is a shift in release strategy, as a new generation of openSUSE releases, this variation on the traditional "starting point" for SUSE versioning makes sense. Not to mention that it's SLE release + 30. I'm sure there are other numerological correlations that could be made as well, probably even including some that involve the numbers 6, 9 and possibly base 13. ;) In the words of Douglas Adams (referring to the selection of "42"): "42 will do." Enjoy the time off, and early Happy Towel Day. :) Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi! On Fri, 2015-06-05 at 00:31 -0700, Atri Bhattacharya wrote:
On Fri, 22 May 2015 14:23:16 +0200, Stephan Kulow wrote:
I would default to openSUSE 42.1 to be next version. But I'm sure a lot of people have other ideas about it.
Not to bikeshed, but personally, I like it. Notwithstanding the Hitchhiker's Guide reference, but the history of the numbers "42" in the SUSE world - SUSE Linux 4.2 being the first release, YaST's first version being 0.42 (which were, as I understand it, references to "The Answer"). Given this is a shift in release strategy, as a new generation of openSUSE releases, this variation on the traditional "starting point" for SUSE versioning makes sense.
Not to mention that it's SLE release + 30. I'm sure there are other numerological correlations that could be made as well, probably even including some that involve the numbers 6, 9 and possibly base 13. ;)
In the words of Douglas Adams (referring to the selection of "42"): "42 will do."
Enjoy the time off, and early Happy Towel Day. :)
Jim
Sorry, didn't mean to resend Jim's email, just hit the wrong button by mistake. Apologies! -- Atri Bhattacharya -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (37)
-
Andrei Borzenkov -
Angelos Tzotsos -
Atri Bhattacharya -
Basil Chupin -
Carlos E. R. -
Carlos E. R. -
Christian Boltz -
Daniele -
Dmitriy Perlow -
Felix Miata -
Frederic Crozat -
Graham P Davis -
Guido Berhoerster -
Jan Engelhardt -
Jim Henderson -
Johannes Kastl -
Knurpht - Gertjan Lettink -
Kyrill Detinov -
Marcus Rueckert -
Michal Hrusecky -
Michal Kubecek -
Olav Reinert -
Patrick Shanahan -
Per Jessen -
Richard Brown -
Robert Kaiser -
Robert Martens -
Robert Schweikert -
Roman Bysh -
Simon Lees -
Stanislav Baiduzhyi -
Stefan Schäfer -
Stefan Seyfried -
Stephan Kulow -
Victor Pereira -
victorhck -
Wolfgang Rosenauer