* 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