On Thu, May 7, 2015 at 4:51 AM, Richard Brown
On 7 May 2015 at 00:42, Greg Freemyer
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@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org