Mailinglist Archive: opensuse-factory (519 mails)

< Previous Next >
[opensuse-factory] openSUSE:42
  • From: Stephan Kulow <coolo@xxxxxxx>
  • Date: Wed, 10 Jun 2015 15:30:13 +0200
  • Message-id: <55783BE5.80905@suse.de>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >