[opensuse-factory] openSUSE:42
Hi, I read all the comments in the thread, but I don't want to reply in this old thread. I think it makes sense to restart the discussions though. There were several topics and I considered splitting my mail, but somehow they all belong together, so this mail will be long ;( [1] The If Me and many others at SUSE believe the current way of releasing is not the best we can do and so SUSE made a decision to release SLE sources for the community to use and help offering a distribution based on it. And the feedback we got was overwhelmingly positive (in big parts quite surprising to me). So I will work on it (because I like the challenge and because it's part of my job now). I don't know all the answers - and that's what makes this whole thing so exciting and frightening at the same time. But I will work on this as openly as I can. Most of it will happen as we make progress anyway ;) [2] The Name/Version There are 2 hard problems in computing: - Caching problems - Naming things - Off-by-One Errors I kind of expected that the version number would create the most mails, but I'm quite disappointed about the net result, because it didn't bring up any alternative IMO. openSUSE:42 is a working title and it's a good one - everyone knows what I'm talking about when I say "42's stagings", but I'm not really happy with it either. The problem is: the next openSUSE release will be very different from what our users are used to. Not so much on first look, but next year we will have basically a minor release ("service pack") for it instead of a major version, so I want to see this expressed. Expressing this in the version number is most likely wrong, but it's the next best thing we can do. So far no one had a good idea and I didn't even try - for good reasons, because I would call it openSUSE Boring Stuff 1. I figure this won't go well with marketing though. As others explained better than I could, 42 has some flair around it. I never read the book nor did I find the movie funny (I enjoyed Ms. Deschanel in it though :) - but I prefer "openSUSE 42" over a plain continuation of our current name+version scheme though. I don't think voting about such things has any relevance. In all honesty: if I don't feel comfortable with the name, a vote won't change that. And I don't feel comfortable with a continuation and 42.1 is the only alternative brought forward so far. [3] The how You would think this is the bigger challenge than the name, but at least we have a 2nd try. If the process we decide for now doesn't work, we can most likely adapt - changing names afterwards is much harder. So I think the process should be as adaptive as human possible. openSUSE:42 will be a separate code stream and it's purpose is different from openSUSE:Factory. While openSUSE:Factory is released every day and contains things close to upstream, in openSUSE:42 we develop a distribution optimized to last long on the user's computer. Basing on SUSE's Enterprise Sources sounds fancy, but of course SLE-12 is in its nature a snapshot of openSUSE:Factory too. But while Tumbleweed ISOs survive a day or sometimes a week, SLE 12 will be in the market for a very long time. Many raised the concern, that SLE 12 is static and old, but that's not really true. "We adapt. You succeed" stands below SUSE's logo - just put a little faith in these words ;) The basic work flow is simple: SUSE sources base the core system, "desktop stuff" comes from Factory initially. But reality is much more fragmented ;( E.g. we have qt5 being too old for fresh KDE or gtk2 too old for fresh GNOME and we have tons of software in general our users expect in openSUSE, SLE does not offer. To make this all work, we have to accept some rules: - we can update every component in openSUSE that SLE would update in service packs too - with or without the consent of the assigned SLE maintainer. But it always comes with a price: updated components have to be maintained by openSUSE - especially if it wasn't with consent of the SLE maintainer. This fortunately applies to gtk2 and qt5 - for now. We can update these in :42 and then later merge with some SLE12 service pack. - we can add as many packages as we dare to maintain - and as feasible. It's very likely that you are stuck with the version you submit today for the next years and there are many cases where it's easier to refer to an OBS repo instead. - we have to be extra careful with replacing SLE sources. It's always an option, but a very expensive one. Not only because of the split in maintenance, but also because of different integration bugs hitting us. - and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR") To make it work, we need to come up with some clever way to track the sources and its origin. This is also the reason the process is so slow, I don't want to throw this together and then later sort it out. To avoid this mail getting even longer, I will stop here - I set my spell checker to Queen's English, but I'm looking forward to the real translation of it :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 10 Jun 2015, Stephan Kulow wrote:
Hi, ... [3] The how ... - and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
To add one of the more interesting challenges here is that iff we succeed in adapting to a compiler other than the GCC 4.8 based one on SLE 12 we face the issue that with GCC 5 the libstdc++6 "default" ABI changed and thus you can't mix programs or libraries built with the old ABI with ones built with the new ABI (well, that's a simplified statement, of course). Now, it might be that openSUSE 42 is not a "add-on" and thus we re-build all packages anyway, even those that are still the same as in SLE 12. Updating the compiler for old SLE 12 packages might be a challenge on itself, of course. So - if the compiler used for building packages stays GCC 4.8 based for the lifetime of openSUSE 42 then any additional compiler we ship has to default to the old libstdc++6 ABI (which is at least possible for GCC 5). Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) -- 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 10.06.2015 15:46, Richard Biener wrote:
On Wed, 10 Jun 2015, Stephan Kulow wrote:
Hi, ... [3] The how ... - and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
To add one of the more interesting challenges here is that iff we succeed in adapting to a compiler other than the GCC 4.8 based one on SLE 12 we face the issue that with GCC 5 the libstdc++6 "default" ABI changed and thus you can't mix programs or libraries built with the old ABI with ones built with the new ABI (well, that's a simplified statement, of course).
Now, it might be that openSUSE 42 is not a "add-on" and thus we re-build all packages anyway, even those that are still the same as in SLE 12.
Updating the compiler for old SLE 12 packages might be a challenge on itself, of course. And I don't think we want to go there. I'm sure you see it differently, but the net value of a new compiler to a random openSUSE user is very small - not worth the trouble inherited with it.
So - if the compiler used for building packages stays GCC 4.8 based for the lifetime of openSUSE 42 then any additional compiler we ship has to default to the old libstdc++6 ABI (which is at least possible for GCC 5).
That sounds like a plan actually :) Greetings, Stephan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlV4QtIACgkQwFSBhlBjoJYcWACfZPauE8bZYA7UApExw9rTGpj5 XLkAn3fwBugYDzICTcdviGclrOimDgNs =kgnt -----END PGP SIGNATURE----- -- 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> Wed, 10 Jun 2015 16:59:51 +0300:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10.06.2015 15:46, Richard Biener wrote:
On Wed, 10 Jun 2015, Stephan Kulow wrote:
Hi, ... [3] The how ... - and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
To add one of the more interesting challenges here is that iff we succeed in adapting to a compiler other than the GCC 4.8 based one on SLE 12 we face the issue that with GCC 5 the libstdc++6 "default" ABI changed and thus you can't mix programs or libraries built with the old ABI with ones built with the new ABI (well, that's a simplified statement, of course).
Now, it might be that openSUSE 42 is not a "add-on" and thus we re-build all packages anyway, even those that are still the same as in SLE 12.
Updating the compiler for old SLE 12 packages might be a challenge on itself, of course. And I don't think we want to go there. I'm sure you see it differently, but the net value of a new compiler to a random openSUSE user is very small - not worth the trouble inherited with it.
Only clang >= 3.4 & gcc >= 4.9 provide true C++14 support so two leechcraft subpackages can't be build even for openSUSE:Factory just now. More and more package will became non-buildable in the future. Actual Qt5 would be fine too.
So - if the compiler used for building packages stays GCC 4.8 based for the lifetime of openSUSE 42 then any additional compiler we ship has to default to the old libstdc++6 ABI (which is at least possible for GCC 5).
That sounds like a plan actually :)
Greetings, Stephan
-- 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 Wed, 10 Jun 2015, Stephan Kulow wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10.06.2015 15:46, Richard Biener wrote:
On Wed, 10 Jun 2015, Stephan Kulow wrote:
Hi, ... [3] The how ... - and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
To add one of the more interesting challenges here is that iff we succeed in adapting to a compiler other than the GCC 4.8 based one on SLE 12 we face the issue that with GCC 5 the libstdc++6 "default" ABI changed and thus you can't mix programs or libraries built with the old ABI with ones built with the new ABI (well, that's a simplified statement, of course).
Now, it might be that openSUSE 42 is not a "add-on" and thus we re-build all packages anyway, even those that are still the same as in SLE 12.
Updating the compiler for old SLE 12 packages might be a challenge on itself, of course. And I don't think we want to go there. I'm sure you see it differently, but the net value of a new compiler to a random openSUSE user is very small - not worth the trouble inherited with it.
So - if the compiler used for building packages stays GCC 4.8 based for the lifetime of openSUSE 42 then any additional compiler we ship has to default to the old libstdc++6 ABI (which is at least possible for GCC 5).
That sounds like a plan actually :)
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;) Currently I have %if 0%{suse_version} <= 1320 --with-default-libstdcxx-abi=c++98 \ %endif so anything older than Factory will use the old ABI by default. IIRC SLE12 has 1315 so anything < 1320 would work for me (of course then 42 will seem "older" than 13.2 ...) Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320. What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary: %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid... Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.06.2015 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
[you guys can stop CCing me, I'm subscribed :]
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid...
The problem is that packages using %suse_version > 1320 might actually be broken on :42 - SLE12's sources are different than what we had when this was done. So I'm afraid there is no good solution - suse_version must die ;( But knowing what strange uses we have for "1315" I'm afraid to touch it. So I would actually go with "%suse_version 1315" and "%opensuse_version 42" and increase suse_version in TW every month or so. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 11 Jun 2015, Stephan Kulow wrote:
On 11.06.2015 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
[you guys can stop CCing me, I'm subscribed :]
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid...
The problem is that packages using %suse_version > 1320 might actually be broken on :42 - SLE12's sources are different than what we had when this was done.
So I'm afraid there is no good solution - suse_version must die ;(
Well... For my particular case a required %define in the project config like %macros %libstdcxx_abi_version 98 (or 11 for the c++11 version) would of course work. Or some other means of injecting such, like having a rpm-branding package that amends /usr/lib/rpm/macros (or even /etc/rpm.d/*) The issue is usually that you only figure out you need sth like that when older trees "break" with new package versions, so you can't really fixup the thing in the old system properly. Thus you'd need to be conservative by default and via some means like the above "enable" the yes-we-are-new-enough path.
But knowing what strange uses we have for "1315" I'm afraid to touch it. So I would actually go with "%suse_version 1315" and "%opensuse_version 42" and increase suse_version in TW every month or so.
I think keeping %suse_version at 1315 is the only sensible way. Not sure why you need %opensuse_version thoguh. If %suse_version has to die the solution can't be to add %opensuse_version ;) Instead the solution is to adopt some (policy) about configuring package builds via the project config or similar means. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.06.2015 13:04, Richard Biener wrote:
I think keeping %suse_version at 1315 is the only sensible way. Not sure why you need %opensuse_version thoguh. If %suse_version has to die the solution can't be to add %opensuse_version ;)
Yes, "has to die" => "can't be used to differ openSUSE:42 releases" Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, 11 Jun 2015 13:07:14 +0200 Stephan Kulow <coolo@suse.de> wrote:
On 11.06.2015 13:04, Richard Biener wrote:
I think keeping %suse_version at 1315 is the only sensible way. Not sure why you need %opensuse_version thoguh. If %suse_version has to die the solution can't be to add %opensuse_version ;)
Yes, "has to die" => "can't be used to differ openSUSE:42 releases"
This wont fly either. As soon as we start upgrading e.g. GNOME in :42, we might need to adapt other packages. Which btw is even the case for service packs sometimes. And the worst part is now ... we could e.g. say SP1 is 1316 but :42 might actually diverge from 12:GA enough to make it need 1316 too. which then block the use for SP1 ... but we only have 4 numbers until we hit 1320. 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 Thursday 2015-06-11 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid...
So let's introduce %sles_version again. It is very much needed as an indicator to a "truncated" (compared to openSUSE) set of packages. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.06.2015 12:59, Jan Engelhardt wrote:
On Thursday 2015-06-11 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
On Thursday 2015-06-11 11:03, Richard Biener wrote:
Yes. Please make sure %suse_version is sensible for openSUSE 42 then (like using the value from SLE12). Not 4200 please ;)
This proposal _has_ to be rejected. It will break about every other package that uses %suse_version <=1320 / >1320.
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
%if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 BuildRequires: libgsasl-devel %endif ... %configure \ %if 0%{?suse_version} != 1110 && 0%{?suse_version} != 1315 --enable-gsasl %endif
Yes, something I'd like to avoid...
So let's introduce %sles_version again. It is very much needed as an indicator to a "truncated" (compared to openSUSE) set of packages.
Yes, that's what we'll have to do. But I guess we also need a way to differ between the real SLE and openSUSE:42. But I would like to avoid a opensuse_version as this has no relevance in TW (there suse_version should continuedly increase). So: suse_version 1315 for the full time life of SLE12 and openSUSE:42 sle_version 1200 for SLE12:GA, 1210 for SLE12:SP1 additionally is_opensuse 1 for openSUSE:42 to mark differences Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Jun 11, Stephan Kulow wrote:
On 11.06.2015 12:59, Jan Engelhardt wrote:
On Thursday 2015-06-11 11:22, Richard Biener wrote:
On Thu, 11 Jun 2015, Jan Engelhardt wrote:
What is worse is that due to absence of %sles_version since SLE12, we now have to special-case versions 1110 and 1315, as in, exemplary:
Version 1110 is not special, it stands for openSUSE 11.1 openSUSE 11.1 and SLES11 shared the same code base, there was no difference except a different set of packages.
Yes, that's what we'll have to do. But I guess we also need a way to differ between the real SLE and openSUSE:42. But I would like to avoid a opensuse_version as this has no relevance in TW (there suse_version should continuedly increase).
So: suse_version 1315 for the full time life of SLE12 and openSUSE:42 sle_version 1200 for SLE12:GA, 1210 for SLE12:SP1 additionally is_opensuse 1 for openSUSE:42 to mark differences
I fully agree to this and think it's the best solution. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2015-06-10 15:30, Stephan Kulow wrote:
[2] The Name/Version I kind of expected that the version number would create the most mails, but I'm quite disappointed about the net result, because it didn't bring up any alternative IMO. openSUSE:42 is a working title and it's a good one
The problem was that you chose a _number_ for a _title_, which, I will argue, contributed significantly to the confusion, and rightfully so.
As others explained better than I could, 42 has some flair around it.
Did you never, in younger years, tell an insider joke, and then landed in the awkward situation that your listeners did not get it? 42 turned out to be one of them.
I don't think voting about such things has any relevance. In all honesty: if I don't feel comfortable with the name, a vote won't change that. And I don't feel comfortable with a continuation and 42.1 is the only alternative brought forward so far.
Because there is not really anything better. As each release is a successor to the prior, they make an ordered set no matter what they care called. People like strictly-monotonically increasing things (numbers, starting letters, etc.). Humanity has also tried random names, but they only make it as far as release codenames.
openSUSE:42 will be a separate code stream and it's purpose is different from openSUSE:Factory. While openSUSE:Factory is released every day and contains things close to upstream, in openSUSE:42 we develop a distribution optimized to last long on the user's computer.
openSUSE seems to be leaning onto E words: Evergreen, Essence/Essential (the new-released SLE base underneath "42"). We could use another E-word for what is "42" if that pleases.
- we can add as many packages as we dare to maintain - and as feasible. It's very likely that you are stuck with the version you submit today for the next years and there are many cases where it's easier to refer to an OBS repo instead.
Yes. Perfectly fine. This is already how openSUSE works w.r.t. some packages.
To make it work, we need to come up with some clever way to track the sources and its origin. This is also the reason the process is so slow, I don't want to throw this together and then later sort it out.
It would seem that the occassional SR from a higher-frequently-updated project to a lower-frequent one seems like a possible way. That is how it is already being done.. (home -> develprj -> factory/tumbleweed -> openSUSE Main -> SLE) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday, June 10, 2015 03:59:48 PM Jan Engelhardt wrote:
On Wednesday 2015-06-10 15:30, Stephan Kulow wrote:
[2] The Name/Version I kind of expected that the version number would create the most mails, but I'm quite disappointed about the net result, because it didn't bring up any alternative IMO. openSUSE:42 is a working title and it's a good one
The problem was that you chose a _number_ for a _title_, which, I will argue, contributed significantly to the confusion, and rightfully so.
As others explained better than I could, 42 has some flair around it.
Did you never, in younger years, tell an insider joke, and then landed in the awkward situation that your listeners did not get it? 42 turned out to be one of them.
I don't think voting about such things has any relevance. In all honesty: if I don't feel comfortable with the name, a vote won't change that. And I don't feel comfortable with a continuation and 42.1 is the only alternative brought forward so far.
Because there is not really anything better. As each release is a successor to the prior, they make an ordered set no matter what they care called. People like strictly-monotonically increasing things (numbers, starting letters, etc.). Humanity has also tried random names, but they only make it as far as release codenames.
openSUSE:42 will be a separate code stream and it's purpose is different from openSUSE:Factory. While openSUSE:Factory is released every day and contains things close to upstream, in openSUSE:42 we develop a distribution optimized to last long on the user's computer.
openSUSE seems to be leaning onto E words: Evergreen, Essence/Essential (the new-released SLE base underneath "42"). We could use another E-word for what is "42" if that pleases.
A number has no emotional meaning attached and make no behavioral responses for marketing purposes. If you like the E-Word let's name it "openSUSE: Eclosion" = "openSUSE: Blooming or Hatch". Now the world love global words to brand. After all, in some way, it would be a new dawn for this project. "Eclosion" is spanish word for a radiant flourishing, blooming, hatching, incubating, dreaming up....It would be the first release with different code. Sure it will have time to brand it if that case matures to see reality. So far we draw it, the main issue is plenty of technical and resource challenges. And after all, why SUSE would release a commercial code? It does not make sense at all. Regards, -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2015-06-10 17:11, Rick Chung wrote:
A number has no emotional meaning attached and make no behavioral responses for marketing purposes.
If that were true, then the world would not be seeing so many elevators without a 4th/13th/... floor. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 10 Jun 2015 10:11:19 -0500 Rick Chung <amon0.thoth1@gmail.com> wrote:
A number has no emotional meaning attached and make no behavioral responses for marketing purposes.
If you like the E-Word let's name it "openSUSE: Eclosion" = "openSUSE: Blooming or Hatch". Now the world love global words to brand. After all, in some way, it would be a new dawn for this project. "Eclosion" is spanish word for a radiant flourishing, blooming, hatching, incubating, dreaming up....It would be the first release with different code.
Sure it will have time to brand it if that case matures to see reality. So far we draw it, the main issue is plenty of technical and resource challenges. And after all, why SUSE would release a commercial code? It does not make sense at all.
Can I be honest ... the *name* should be the *last* thing we worry about. We should focus on getting the plan for "something to release" first. as it was mentioned already ... opensuse:42 is a working title. just my 2 cents 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 Wednesday, June 10, 2015 05:47:07 PM Marcus Rückert wrote:
On Wed, 10 Jun 2015 10:11:19 -0500
Rick Chung <amon0.thoth1@gmail.com> wrote:
A number has no emotional meaning attached and make no behavioral responses for marketing purposes.
If you like the E-Word let's name it "openSUSE: Eclosion" = "openSUSE: Blooming or Hatch". Now the world love global words to brand. After all, in some way, it would be a new dawn for this project. "Eclosion" is spanish word for a radiant flourishing, blooming, hatching, incubating, dreaming up....It would be the first release with different code.
Sure it will have time to brand it if that case matures to see reality. So far we draw it, the main issue is plenty of technical and resource challenges. And after all, why SUSE would release a commercial code? It does not make sense at all.
Can I be honest ... the *name* should be the *last* thing we worry about. We should focus on getting the plan for "something to release" first. as it was mentioned already ... opensuse:42 is a working title.
just my 2 cents
darix
+10000 That's it. 100% -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op woensdag 10 juni 2015 17:47:07 schreef Marcus Rückert:
On Wed, 10 Jun 2015 10:11:19 -0500 Can I be honest ... the *name* should be the *last* thing we worry about. We should focus on getting the plan for "something to release" first. as it was mentioned already ... opensuse:42 is a working title.
just my 2 cents
darix
A big +1 -- 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
* Stephan Kulow <coolo@suse.de> [2015-06-10 15:30]:
Hi,
I read all the comments in the thread, but I don't want to reply in this old thread. I think it makes sense to restart the discussions though.
There were several topics and I considered splitting my mail, but somehow they all belong together, so this mail will be long ;(
[1] The If
Me and many others at SUSE believe the current way of releasing is not the best we can do and so SUSE made a decision to release SLE sources for the community to use and help offering a distribution based on it. And the feedback we got was overwhelmingly positive (in big parts quite surprising to me). So I will work on it (because I like the challenge and because it's part of my job now).
I've watched the Richard's presentation and read your previous mail but I'm still don't quite get the "why", at least not the net benefit for the project as a whole and our users. I can understand that it may be appealing to those package maintainers who maintain three braches of their packages (SLE, openSUSE release and Factory) or who only care about Factory. The main benefit for openSUSE *users* mentioned has been stability. But following your proposal this "stability" would only affect a small part of the distribution, i.e. kernel, glibc, systemd, coreutils, upower and so on but not desktop environments or applications. Is instability of these selected components actually that big of a problem in practice? Of course I'm aware and see a spike of bug reports *after* a release because people didn't test before, but how much of that actually concerns the proposed stable components?
The basic work flow is simple: SUSE sources base the core system, "desktop stuff" comes from Factory initially. But reality is much more fragmented ;(
E.g. we have qt5 being too old for fresh KDE or gtk2 too old for fresh GNOME and we have tons of software in general our users expect in openSUSE, SLE does not offer.
To make this all work, we have to accept some rules: - we can update every component in openSUSE that SLE would update in service packs too - with or without the consent of the assigned SLE maintainer. But it always comes with a price: updated components have to be maintained by openSUSE - especially if it wasn't with consent of the SLE maintainer. This fortunately applies to gtk2 and qt5 - for now. We can update these in :42 and then later merge with some SLE12 service pack.
- we can add as many packages as we dare to maintain - and as feasible. It's very likely that you are stuck with the version you submit today for the next years and there are many cases where it's easier to refer to an OBS repo instead.
- we have to be extra careful with replacing SLE sources. It's always an option, but a very expensive one. Not only because of the split in maintenance, but also because of different integration bugs hitting us.
- and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
As you suggested already here is no clear seperation between desktop environments and a "base system", there is little abstraction and high and low-level components are increasingly tightly coupled, e.g. what do we do the next time the upower, NetworkManager or login API is bumped and the following GNOME, KDE, or Xfce release requires the new API version? Options are either to update and from then on maintain the low-level component, that is after a few releases to end up with the same situation as we have now, or to be stuck with a certain version of the desktop environment which will become unsupported by upstream and burden the openSUSE maintainers. Neither sounds desirable to me. Then there is the issue of consumer hardware support, and I don't find the SLE hardware enablement convincing at all. It also strikes me that not all packages from Factory will be available in 42. AFAICS the main problems we have are: - a lack of manpower in release engineering - a lack of manpower in maintaining core components, in particular work-intensive ones like the kernel and systemd - no marketing So possible benefits are: - no more seperate maintenance of core components, less work mostly for SUSE staff who maintain those packages - greater stability of these components due to more testing, SLE QA work whereas possible drawbacks are: - likely less supported (consumer) hardware - likely less packages - aforementioned problems combining new high-level components with old low-level components, possibly resulting in more work after some time - losing users and contributors who are not served by this model With all its problems I use and contribute to openSUSE because it delivers a certain balance of stability and resonably new software every 8 to 12 months and because it has a lot of stuff packaged, something I do not get from other distros such as Debian (too outdated), Ubuntu or Fedora (too much breakage). Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors. -- 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 06/10/2015 11:04 AM, Guido Berhoerster wrote:
* Stephan Kulow <coolo@suse.de> [2015-06-10 15:30]:
Hi,
I read all the comments in the thread, but I don't want to reply in this old thread. I think it makes sense to restart the discussions though.
There were several topics and I considered splitting my mail, but somehow they all belong together, so this mail will be long ;(
[1] The If
Me and many others at SUSE believe the current way of releasing is not the best we can do and so SUSE made a decision to release SLE sources for the community to use and help offering a distribution based on it. And the feedback we got was overwhelmingly positive (in big parts quite surprising to me). So I will work on it (because I like the challenge and because it's part of my job now).
I've watched the Richard's presentation and read your previous mail but I'm still don't quite get the "why", at least not the net benefit for the project as a whole and our users. I can understand that it may be appealing to those package maintainers who maintain three braches of their packages (SLE, openSUSE release and Factory) or who only care about Factory. The main benefit for openSUSE *users* mentioned has been stability. But following your proposal this "stability" would only affect a small part of the distribution, i.e. kernel, glibc, systemd, coreutils, upower and so on but not desktop environments or applications. Is instability of these selected components actually that big of a problem in practice? Of course I'm aware and see a spike of bug reports *after* a release because people didn't test before, but how much of that actually concerns the proposed stable components?
The basic work flow is simple: SUSE sources base the core system, "desktop stuff" comes from Factory initially. But reality is much more fragmented ;(
E.g. we have qt5 being too old for fresh KDE or gtk2 too old for fresh GNOME and we have tons of software in general our users expect in openSUSE, SLE does not offer.
To make this all work, we have to accept some rules: - we can update every component in openSUSE that SLE would update in service packs too - with or without the consent of the assigned SLE maintainer. But it always comes with a price: updated components have to be maintained by openSUSE - especially if it wasn't with consent of the SLE maintainer. This fortunately applies to gtk2 and qt5 - for now. We can update these in :42 and then later merge with some SLE12 service pack.
- we can add as many packages as we dare to maintain - and as feasible. It's very likely that you are stuck with the version you submit today for the next years and there are many cases where it's easier to refer to an OBS repo instead.
- we have to be extra careful with replacing SLE sources. It's always an option, but a very expensive one. Not only because of the split in maintenance, but also because of different integration bugs hitting us.
- and IMO we need to keep a defined compatibility with SLE 12. I don't know yet how that should look like, but we need to define use cases that should work and test it (something along "install the rpm of FOOBAR for sle12 on openSUSE 42 and start FOO to test BAR")
As you suggested already here is no clear seperation between desktop environments and a "base system", there is little abstraction and high and low-level components are increasingly tightly coupled, e.g. what do we do the next time the upower, NetworkManager or login API is bumped and the following GNOME, KDE, or Xfce release requires the new API version? Options are either to update and from then on maintain the low-level component, that is after a few releases to end up with the same situation as we have now, or to be stuck with a certain version of the desktop environment which will become unsupported by upstream and burden the openSUSE maintainers. Neither sounds desirable to me.
Then there is the issue of consumer hardware support, and I don't find the SLE hardware enablement convincing at all. It also strikes me that not all packages from Factory will be available in 42.
AFAICS the main problems we have are: - a lack of manpower in release engineering - a lack of manpower in maintaining core components, in particular work-intensive ones like the kernel and systemd - no marketing
So possible benefits are: - no more seperate maintenance of core components, less work mostly for SUSE staff who maintain those packages - greater stability of these components due to more testing, SLE QA work
whereas possible drawbacks are: - likely less supported (consumer) hardware - likely less packages - aforementioned problems combining new high-level components with old low-level components, possibly resulting in more work after some time - losing users and contributors who are not served by this model
With all its problems I use and contribute to openSUSE because it delivers a certain balance of stability and resonably new software every 8 to 12 months and because it has a lot of stuff packaged, something I do not get from other distros such as Debian (too outdated), Ubuntu or Fedora (too much breakage). Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
+1 Well said, thank you Guido - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVeHc+AAoJEE4FgL32d2UkxSYH/jCkMKVFYR+mtj5oUmv618Sw rXUTKj6zdQ3gugf6Q9p194jm9o/RASXjBiyYJWn0RJSztPlTsWRfLeCODgiRmciE cKhxeNI+fnuuZqFhHjqviJPfw9AAC9Ja+J28rar/zHiOwxvaeLbNgu42Jn55HaZN wGRrEk/ukYOMS3uyO5wRMiU6I7TIKm2byNPJGlF02ITexG//vdy2fowzCOezYa2Q aHugGYmg9BheE4oK5Bkc+6MCINbiRtJos1Km1jiC8bZ6lv5Tdj7euz+Y13jwwOjn hKsKYAk46iTgfebfxI1wOGvEuQiNPIe9PKzm7Wo+92vogcSBGgMfsZLDh90JEcs= =9qnB -----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-06-10 19:43, Robert Schweikert wrote:
On 06/10/2015 11:04 AM, Guido Berhoerster wrote:
* Stephan Kulow <> [2015-06-10 15:30]:
With all its problems I use and contribute to openSUSE because it delivers a certain balance of stability and resonably new software every 8 to 12 months and because it has a lot of stuff packaged, something I do not get from other distros such as Debian (too outdated), Ubuntu or Fedora (too much breakage). Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
+1
Well said, thank you Guido
Same here. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlV4eeQACgkQtTMYHG2NR9V+EgCcC5zNlOYPMoEkq8rfpxMHeJiX oeoAnAmS6D9fhuwrmUQ0WyZb/WnMM1Cd =T9Q0 -----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-06-10 19:54, Carlos E. R. wrote:
On 2015-06-10 19:43, Robert Schweikert wrote:
On 06/10/2015 11:04 AM, Guido Berhoerster wrote:
* Stephan Kulow <> [2015-06-10 15:30]:
+1
Well said, thank you Guido
Same here.
I forgot another one: Factory/Tumbleweed now will be of no interest to me. Previously I would do a test install, which would seamlessly update into the stable release. I would report bugs on it, hoping to have them solved for the stable. Now I see no reason to install it at all... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlV5jK8ACgkQtTMYHG2NR9WQcgCdG7EC5AUNowFWukShHhmR5ZjB vd4AniU844T4ULZ9flmwUaYw1huofd82 =+1rM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.06.2015 um 17:04 schrieb Guido Berhoerster:
Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
Yes. I won't deny it. And changing that balance means also potentially adding to our base of users and contributors. I can't say which is more likely - all I know is that we tried long enough with the current model to know that it has no bright future. All I can ask you is give the new model a chance - there are still many variables you can influence if you tried. I actually wished more people would go ahead and stretch ways to solve the issues they see with the rules I gave instead of saying NO. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 10.06.2015 um 23:04 schrieb Stephan Kulow:
All I can ask you is give the new model a chance - there are still many variables you can influence if you tried. I actually wished more people would go ahead and stretch ways to solve the issues they see with the rules I gave instead of saying NO.
Even though I am a happy user of the old "snapshot once per year and keep that snapshot running for two years" model (for my "customers" at home) and of the old/new Factory (for my personal notebook), I do understand that it is not easy getting together the people to actually do the work on that stable snapshot releases. I also think that we can benefit from professional SLES maintenance. So I will try to help the new model as much as possible (by technical means, I never did any management job and will avoid doing so in the future). And in the end: if we find out that this openSUSE:Boring approach is not going to work well, it is not hard at all to switch back to the "cut a snapshot once per year". So let's be brave and just try it. seife -- 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
* Stephan Kulow <coolo@suse.de> [2015-06-10 23:04]:
Am 10.06.2015 um 17:04 schrieb Guido Berhoerster:
Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
Yes. I won't deny it.
And changing that balance means also potentially adding to our base of users and contributors.
It seems that every year we have to have this same discussion of fundamentally changing our development model, target users and goals of openSUSE under which the current community operates. I would rather appreciate a discussion of how we can address the actual underlying problems.
I can't say which is more likely - all I know is that we tried long enough with the current model to know that it has no bright future.
I disagree with that, we just changed the development model of Factory a year ago and we have not had a stable release come out of that development model. Due to the greater exposure of Factory/Tumbleweed had I would expect a much higher quality at release time compared to the previous couple of releases. A new development model and target audience might be something exciting to market but after the first releases that effect will eventually wane and we'll be back to where we are now in terms of marketing. It may attract new users who e.g. want to run openSUSE on their servers or build an applicance on top of it, but it will also drive off other users and contributors. Even a net gain in users does not necessarily translate into a net gain of contributors. If you take the Evergreen project as an indicator, despite its success and the interest that is visible from the mailinglist it hasn't had a great influx of new contributors and is still run by the same two or three people that started it.
All I can ask you is give the new model a chance - there are still many variables you can influence if you tried. I actually wished more people would go ahead and stretch ways to solve the issues they see with the rules I gave instead of saying NO.
I did not simply say "no", but I'm also not sold to the idea and I do have some concerns and questions with the outlined plan which would greatly diminish the utility of openSUSE releases for me (and from what I've seen some other contributors as well) and haven't found it reassuring how some of these questions were simply shrugged off (not by you but others in the initial thread you started). If we commit to the model you laid out without addressing these issues now, I fear there will be no turning back later without much additional cost and friction. In particular, because apart from the missing packages these issues will only become visible and problematic after some time over the lifetime of SLE12. I'd be much more able to embrace and participate in the effort if there was some reassurement and commitment by SUSE to provide manpower to either enable, maintain and backport drivers for consumer-level hardware even without a business case for SLE or to support a separate openSUSE kernel for each release as it currently done. Furthermore, I see no reason why it should not be a requirement to include all packages from Factory which are *not yet in openSUSE:42. After all that is the deal we have now, if you submit stuff to Factory you commit to maintain it in a release. It doesn't have to happen all at once but should be a goal before a stable release. Based on my own observations and after watching the recording of the OSC community meeting - there seems an abundance of contributors maintaining high-level packages - but a shortage of contributors taking care of complex and low-level components such as the kernel, systemd etc. - there is a lack of manpower for - release engineering, - infrastructure maintenance, - documentation (particularly the wiki), - advocacy and marketing The above issues seem to be very much a consequence of how openSUSE has grown, it has become open to outsiders but it is not fully owned by the community. A lot of shortage is in areas which used to be taken care of by SUSE but from which it has withdrawn without non-SUSE community members stepping in, particularly in areas which require a high level of skills but offer little rewards. So I think it's unrealistic to expect new people stepping in and helping with these complex tasks, at least not in the short term. Without marketing and advocay we can offer the best technology (and I think we already do offer great technology and have a very low barrier of entry) and will still remain in an obscure corner. I don't know how to change that, it's a complex, not purely technical problem so it demans a complex answer and would prefer a discussion about that or we will be back next year with the same discussion of moving things around again. -- 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 06/12/2015 08:13 AM, Guido Berhoerster wrote:
* Stephan Kulow <coolo@suse.de> [2015-06-10 23:04]:
Am 10.06.2015 um 17:04 schrieb Guido Berhoerster:
Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
Yes. I won't deny it.
And changing that balance means also potentially adding to our base of users and contributors.
It seems that every year we have to have this same discussion of fundamentally changing our development model, target users and goals of openSUSE under which the current community operates. I would rather appreciate a discussion of how we can address the actual underlying problems.
I can't say which is more likely - all I know is that we tried long enough with the current model to know that it has no bright future.
I disagree with that, we just changed the development model of Factory a year ago and we have not had a stable release come out of that development model. Due to the greater exposure of Factory/Tumbleweed had I would expect a much higher quality at release time compared to the previous couple of releases.
A new development model and target audience might be something exciting to market but after the first releases that effect will eventually wane and we'll be back to where we are now in terms of marketing. It may attract new users who e.g. want to run openSUSE on their servers or build an applicance on top of it, but it will also drive off other users and contributors. Even a net gain in users does not necessarily translate into a net gain of contributors. If you take the Evergreen project as an indicator, despite its success and the interest that is visible from the mailinglist it hasn't had a great influx of new contributors and is still run by the same two or three people that started it.
All I can ask you is give the new model a chance - there are still many variables you can influence if you tried. I actually wished more people would go ahead and stretch ways to solve the issues they see with the rules I gave instead of saying NO.
I did not simply say "no", but I'm also not sold to the idea and I do have some concerns and questions with the outlined plan which would greatly diminish the utility of openSUSE releases for me (and from what I've seen some other contributors as well) and haven't found it reassuring how some of these questions were simply shrugged off (not by you but others in the initial thread you started).
If we commit to the model you laid out without addressing these issues now, I fear there will be no turning back later without much additional cost and friction. In particular, because apart from the missing packages these issues will only become visible and problematic after some time over the lifetime of SLE12.
I'd be much more able to embrace and participate in the effort if there was some reassurement and commitment by SUSE to provide manpower to either enable, maintain and backport drivers for consumer-level hardware even without a business case for SLE or to support a separate openSUSE kernel for each release as it currently done.
Furthermore, I see no reason why it should not be a requirement to include all packages from Factory which are *not yet in openSUSE:42. After all that is the deal we have now, if you submit stuff to Factory you commit to maintain it in a release. It doesn't have to happen all at once but should be a goal before a stable release.
Based on my own observations and after watching the recording of the OSC community meeting
- there seems an abundance of contributors maintaining high-level packages - but a shortage of contributors taking care of complex and low-level components such as the kernel, systemd etc. - there is a lack of manpower for - release engineering, - infrastructure maintenance, - documentation (particularly the wiki), - advocacy and marketing
The above issues seem to be very much a consequence of how openSUSE has grown, it has become open to outsiders but it is not fully owned by the community. A lot of shortage is in areas which used to be taken care of by SUSE but from which it has withdrawn without non-SUSE community members stepping in, particularly in areas which require a high level of skills but offer little rewards. So I think it's unrealistic to expect new people stepping in and helping with these complex tasks, at least not in the short term. Without marketing and advocay we can offer the best technology (and I think we already do offer great technology and have a very low barrier of entry) and will still remain in an obscure corner. I don't know how to change that, it's a complex, not purely technical problem so it demans a complex answer and would prefer a discussion about that or we will be back next year with the same discussion of moving things around again.
Thanks Guido, I agree Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVes+kAAoJEE4FgL32d2Uk+vcH/i4Yyphyny6HG2BL0WWSSBKH w7g9WIOV3v80gzYHqsDER9lcgvtNll+Mc9vzX10S9C9eKLPHuKApg4aqgWYRI6bq 6hjmaZyI9U0EeqiEf5W39bExhY9NcIQp8bJk9gsZ/mNnSwW8juZFaRCcg7yc+OnK Z5WQBvovZKgaenVYIjd4QIRxK5syq1+0lGeEEJLx5REt3XoK/vAiySw/IktcpuBs 33nV9xVdJSs0j4CIbwDV07ItdwZY0lhpIafisiceNEqpzooqDxeeMzc0Inje9l9E AVP5ASa21AkwchDE+spZID1CKYDKJwsxkz/yaN0E6CG7RwPSc58ucIeq6iZaomg= =PWWp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2015-06-12 14:13, Guido Berhoerster wrote:
- there seems an abundance of contributors maintaining high-level packages - but a shortage of contributors taking care of complex and low-level components such as the kernel, systemd etc.
Add: browsers, compilers. These three groups try to do everything under the sun, and the kitchen sink, and their components are often so intwined with one another (some sell that as "integration") that it is way too easy to break it. Build time is also an issue, we're talking about >1 hour for kernel and e.g. chrome. The average turnaround time people are willing to wait for build results is 2 to 5 MINUTES. So, yes, _of course_ you will see more maintainers on "easy" packages like kmahjongg which "does one thing, (and then well)". -- 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-06-12 14:50, Jan Engelhardt wrote:
So, yes, _of course_ you will see more maintainers on "easy" packages like kmahjongg which "does one thing, (and then well)".
Hopefully, people can gain experience with easy packages, and eventually, progress to more difficult tasks. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlV632oACgkQja8UbcUWM1w73QD+KquIm2g9+1aLgyp8cHJjV91u 2sFZVPOn8Y7V1Td8T2YBAJLPObIJr7bgQxQPUDbwFeTa07lrq6D9ps7XliM/Ml+m =HtpQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.06.2015 um 14:13 schrieb Guido Berhoerster:
I'd be much more able to embrace and participate in the effort if there was some reassurement and commitment by SUSE to provide manpower to either enable, maintain and backport drivers for consumer-level hardware even without a business case for SLE or to support a separate openSUSE kernel for each release as it currently done.
The participation of kernel developers is this discussion (not just this thread) is unfortunately very, very low. Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I’ll quickly jump in to just say that I am very interested in helping with testing this project/work as a server OS. I offer whatever time and assistance I can to that end. Sincerely, Bob Martens
On Jun 12, 2015, at 8:58 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 12.06.2015 um 14:13 schrieb Guido Berhoerster:
I'd be much more able to embrace and participate in the effort if there was some reassurement and commitment by SUSE to provide manpower to either enable, maintain and backport drivers for consumer-level hardware even without a business case for SLE or to support a separate openSUSE kernel for each release as it currently done.
The participation of kernel developers is this discussion (not just this thread) is unfortunately very, very low.
Greetings, Stephan
-- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- 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 Wed, 10 Jun 2015 17:04:18 +0200 Guido Berhoerster wrote:
AFAICS the main problems we have are: - a lack of manpower in release engineering - a lack of manpower in maintaining core components, in particular work-intensive ones like the kernel and systemd - no marketing
So possible benefits are: - no more seperate maintenance of core components, less work mostly for SUSE staff who maintain those packages - greater stability of these components due to more testing, SLE QA work
whereas possible drawbacks are: - likely less supported (consumer) hardware - likely less packages - aforementioned problems combining new high-level components with old low-level components, possibly resulting in more work after some time - losing users and contributors who are not served by this model
With all its problems I use and contribute to openSUSE because it delivers a certain balance of stability and resonably new software every 8 to 12 months and because it has a lot of stuff packaged, something I do not get from other distros such as Debian (too outdated), Ubuntu or Fedora (too much breakage). Changing that balance of hardware support, coverage of packages, recent version and stability means also potentially exchanging or losing parts of our base of users and contributors.
I totally agree with Guido. +1 -- WBR Kyrill
I don't have much useful stuff to contribute here, but... Am 10.06.2015 um 15:30 schrieb Stephan Kulow:
do. So far no one had a good idea and I didn't even try - for good reasons, because I would call it openSUSE Boring Stuff 1.
I like that. openSUSE Boring => SLE based openSUSE eXciting => Factory :-P -- 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 Wed, Jun 10, 2015 at 1:57 PM, Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
I don't have much useful stuff to contribute here, but...
Am 10.06.2015 um 15:30 schrieb Stephan Kulow:
do. So far no one had a good idea and I didn't even try - for good reasons, because I would call it openSUSE Boring Stuff 1.
I like that.
openSUSE Boring => SLE based openSUSE eXciting => Factory
My marketing spin is a little different: openSUSE Boring => The perfect distro for users that like to control their destiny. With SLE as a base you can use openSUSE Boring to drill into OBS for nuggets of excitement while having confidence that you have a stable base to explore from (and return to if needed). ---- As a user, I'd actually like that. I really don't care much about being sucked into the virtual wars (sysVinit vs systemd / KDE3 vs KDE4 ), but there are userspace projects I like pulling from OBS so I know I'm getting the latest. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hey, On 10.06.2015 15:30, Stephan Kulow wrote:
There were several topics and I considered splitting my mail, but somehow they all belong together, so this mail will be long ;(
How about we start tracking proposals/status on some other medium so we don't have to go through long mails again and again? Something like https://en.opensuse.org/openSUSE:42 Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (17)
-
Carlos E. R. -
Carlos E. R. -
Dmitriy Perlow -
Greg Freemyer -
Guido Berhoerster -
Henne Vogelsang -
Jan Engelhardt -
Knurpht - Gertjan Lettink -
Kyrill Detinov -
Marcus Rückert -
Richard Biener -
Rick Chung -
Robert Martens -
Robert Schweikert -
Stefan Seyfried -
Stephan Kulow -
Thorsten Kukuk