Mailinglist Archive: opensuse-project (244 mails)

< Previous Next >
Re: [opensuse-project] After the Richard talk... what's new for openSUSE
On Thu, May 7, 2015 at 4:51 AM, Richard Brown <RBrownCCB@xxxxxxxxxxxx> wrote:
On 7 May 2015 at 00:42, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:
Who will work on SLE based openSUSE? I doubt Tumbleweed packagers will move
3-4 years back in time trying to build stuff. At least some Tumbleweed
packagers care about the Tumbleweed based releases, of course mostly around
release time when they're still 98% identical to Tumbleweed.

Martin,

I think you are missing a big part of the picture: SLE Point releases:
http://en.wikipedia.org/wiki/SUSE_Linux_distributions#Suse_distributions

So SLE 11 and 12 point releases came out

11.0 2009-03-24
11.1 2010-06-02
11.2 2012-02-29
11.3 2013-07-01
12.0 2014-10-10

As I understand it SLE Core would be updated with each point release.
And those point releases are rather all inclusive so you often get a
new kernel and software stack.

So SLE core would not be 3-4 years behind Tumbleweed as I understand it.

If SLE Corp is indeed the future base for openSUSE releases, then
shouldn't the release schedule for openSUSE be based on SLE Core
updates?

Meaning the above dates plus some time to formalize an openSUSE
release around them. Or if SLE freezes SLE core months in advance of
the above, then the openSUSE release could even preceed the point
releases.

That's something we're certainly considering. We might have a
situation where openSUSE/OBS gets the SLE sources once they're
relatively frozen (eg. Betas) which would enable the community to get
building ontop of it before the release of SLE 12.x


When did SLE 12 freeze the kernel version? As I recall it was in the
spring of 2014. If X was also version frozen in the spring, openSUSE
could have done a summer 2014 release and preceeded SLE 12 by months.

That theoretical timeline is a little on the ambitious side (at least
for our first 'new openSUSE' releases) - I think we're going to have
to take our time to learn how to build stuff right in this new
approach, but yes, broadly speaking, I think you're thinking along the
right track and this is the kind of thing I want to see.


What I don't have any feel for is what happens at end of support.

Specifically SLE 11.0 was only supported for 21 months (without
upgrading to 11.1). So how would an openSUSE release based on 11.0 be
supportable past the 11.0 end-of-support?

To me the best option is to base both the release schedule and the
end-of-support schedule on the SLE point release and end-of-support
schedules. The trouble with that is support lifetime of SLE point
releases isn't fundamentally longer than openSUSE release's supported
life.

The way I currently see this working is something like this.. *note
all of these dates and version numbers are TOTALLY MADE UP and nothing
to with reality, and are just to illustrate the theoretical
progression*

openSUSE $NewVersion.1 - Based on SLE 12 SP1 - Theoretical Release Q4 this
year

openSUSE $NewVersion.2 - Based on SLE 12 SP2 - Theoretical Release Q4 2016
Support for openSUSE $NewVersion.1 ends 6 months later (in line with SLE 12
SP1)

openSUSE $NewVersion.3 - Based on SLE 12 SP3 - Theoretical Release Q4 2017
Support for openSUSE $NewVersion.2 ends 6 months later (in line SLE 12 SP2)

openSUSE $NewVersion+1.0 - Based on SLE 13 - Theoretical Release Q4 2018
Support for openSUSE $NewVersion.3 ends X months later (almost
certainly longer than 6 months, to help with transitions)
The current value of X that is being kicked around is something like
12 months, but possibly could be as much as 3 years, depends on a
combination of factors, like how long SUSE are willing to maintain the
Shared 12 SP3 Core, and how long makes sense for openSUSE to maintain
our stuff on top of it.

So, in short terms, this would mean that each openSUSE $New point
release would be supported for at least 18 months (longer if the
release takes longer to come out), with the last release having a
longer time to handle the transition to the big new codebase.

With the exception of the extra long duration of the .3 release, I
realise this theoretical scenario might appear to be very similar to
the status quo, but by using the Shared SLE Sources, the impact of
these 'minor version bumps' will be significantly smaller than
openSUSE's old version bumps (where every one was a major jump, every
time), so there is a strong case to be made that people should be
comfortable jumping in that 6 month window every time.

What do you think?


You seem to be implying the last SLE point release for a major version
is supported by SLE for 2+ years. Is that a valid statement?

If so, I think this summary of your proposal is accurate:

- opensuse implement the same major / point release mechanism that SLE uses

- After new point releases, opensuse users would have 6 months of
support in which to transition to the new point release

- After major releases opensuse users would have 12 months (or more)
of support minimum to allow a scheduled transition

====
Pros - it puts us in sync with SLE and allows us to leverage SLE Core

Cons - it is no longer possible for an opensuse user to skip a
release. ie. the overlapping support in the current model allows
someone running a stable setup to only upgrade every other opensuse
release and still maintain support the who time.

===
Questions

1) I don't know what the SLE major upgrade support policy is, but is
it feasible to have opensuse support the last point release of a major
release until at least 6 months after the next point release.

ie. Support the last 12.x release until 6 months after 13.1 is
available. That way even if 13.0 turns out to have major problems,
one can hope they are resolved in the first 13.1 point release.

2) How would Evergreen fit in? Does it disappear? Does it extend the
support of the last point release in a major series only?
===

Thoughts:

I don't want to be forced to upgrade a server to a .0 release (in the
new naming convention).

If the 13.0 / 14.0 / etc major releases can be skipped by opensuse
users needing stability on servers/etc, I like this proposal. If not,
I don't.

I don't care if enabling .0 major release skipping is enabled via
normal openSUSE support of only via Evergreen support. I just want
that option.

Greg

.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >