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