Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
Re: [opensuse-factory] How Leap and SLE's timetable overlap

Sent from my iPad
On 25 May 2016, at 01:24, Greg Freemyer <greg.freemyer@xxxxxxxxx> wrote:

On Tue, May 24, 2016 at 6:38 PM, Richard Brown <RBrownCCB@xxxxxxxxxxxx>
In another thread, Yamaban brainstormed the following kind of schedule
for future Leap/SLE releases

On 25 May 2016 at 00:20, Yamaban <foerster@xxxxxxxx> wrote:

In light of the LTS kernel the only thing would be to move the
release date of Leap / SLE, e.g.
- Kernel in January / settling in Tumbleweed
- Leap first Alpha in late February / early March
- Leap first Beta mid/late April
- SLE (sp) first Alpha early May
- Leap freeze late May
- SLE (sp) first Beta mid June
- Leap last full patch pull-in / first RC mid/late June
- SLE (sp) freeze early July / or better mid August
- Leap release mid/late July
- SLE (sp) last full patch pull-in / first RC early / mid September
- SLE (sp) release early / mid October

I want to compare that to where we are right now with SLE 12 SP2 and Leap

* Kernel in January / settling in Tumbleweed
* SLE 12 SP2 Alphas in Q1 2016
* SLE 12 SP2 Beta started late May <- NOTE: Leap 42.2 Development
cannot start in earnest until SLE sources are available, and SLE
sources cannot be available until Beta
* Leap 42.2 first Alpha TODAY <- THIS IS WHERE WE ARE :)
* Leap Alphas & SLE Betas over the next few months (aka 'Q2')
* Leap Betas & SLE RC's after that (aka 'Q3')
* SLE 12 SP2 Release in 'Q4'
* Leap RC's in late Sept/October
* Leap 42.2 Release in November

Benefits of this current approach over what Yamaban proposed (Leap &
SLE interleaved)

1. Leap release is still in November, which in 10 years of openSUSE
releases we've proven that releases at that time for year works for us
- Winter/Spring releases get too disrupted by Christmas, Summer
releases get disrupted by summer holidays. October/November is the
time that works for us best.
2. There is a nice symmetry of what we are doing with Leap and what
SUSE are doing with SLE. Our major milestones are aligned. Developers
working on SLE are directly benefiting Leap and visa versa
3. This timeline has the possibility for stuff like SUSE QA engineers
actually working on Leap when SLE development is wrapping up but Leap
will be at the prime interesting time of RC's and GMC.
4. We'll avoid the situation we had with 42.1 (where Leap released a
few weeks before SLE 12 SP1) and then we had a pretty huge 'mega
update' to sync up Leap 42.1 with the SLE 12 SP1 shared packages
5. It accepts the reality that Leap is a fair bit bigger (in terms of
package numbers) than SLE - I think Yamabans suggested timeline is a
little too aggressive. Even if we could realistically start Leap
development before our base system had even started to come together,
trying to properly integrate our 8000+ source packages in that kind of
timescale is pretty much impossible.

Downsides of the Yamaban proposed approach (the "Leap before SLE" schedule)

1. Um..actually I'm no sure there is any benefit..a July release is
pretty much impossible when most of the community goes on vacation
over summer..releasing that much earlier than SLE means we'll have to
miss out on a whole bunch of stuff or have a rough few months keeping
everything in sync as SLE comes I WANTED to
try and write a balanced approach but I think our current roadmap is
the absolute best plan we can have given our desire to release
something annually and with what SUSE are planning for SLE 12 SP2

I'm pretty much in agreement that accelerating 42.2 release schedule
makes little sense..

But, we all know that one of the major issues for the whole Leap
concept was the SLE kernel was too old, so it was decided with 42.1 to
use the most recent LTS kernel at the time of release.

The newly decided kernel LTS release schedule is to do a LTS release
early each year. This year it is the 4.4 kernel released Jan 10,
2016. It will be roughly 10 months old when Leap 42.2 is released.

I don't have a solution, but I personally find that contradictory to
expectations for a Leap kernel.

Brainstorming below:

My thoughts as to options are:

1) delay the full Leap release until early year so the yearly LTS
kernel can be incorporated

I could live with that but I don't like it.

2) Maintain the Nov 42.2 release date, but do a 42.2 "advanced kernel"
release 6 months after 42.2 is released that updates the kernel to the
2017 LTS kernel

---> Note that the 42.1 kernel is scheduled to go out of support 6
months after 42.2 is released

---> Note that if SLE is going to do a summer 2017 SP, then having the
kernel released into Leap 3 to 6 months earlier will allow them to get
useful wide scale testing in advance.

More brainstorming:

if the kernel team is willing to support 2 kernels simultaneously (as
they have done for the last decade plus), then we could have:

- Every Fall do a a full Leap release, but based on the roughly 10
month old LTS kernel of the year. Have the fall Leap kernel supported
for exactly 12 months after the fall Leap version is released.

- Every Spring do a "advanced Kernel" release based on the annual LTS
kernel. Support the "advanced kernel" for the last 12 months of that
Leap version's support.

- During the last 6 months of each Leap version's support, only
support the Advance LTS kernel released in the spring after the
initial release.


Nov 2016 - Release Leap 42.2 with 4.4 kernel

Spring 2017 - Release the Leap 42.2 "advanced kernel" (ie. the 2017
LTS kernel).

Fall 2017 - Release Leap 42.3 with the 2017 LTS kernel (no longer
designated advanced).

Fall 2017 - Drop all support for the 4.4 kernel when Leap 42.3 is released

Spring 2018 - Release the 42.3 "advanced kernel" (ie. the 2018 LTS kernel)

Spring 2018 - Drop 2017 LTS kernel support (when Leap 42.2 support is

The end result is that over the summer 2 kernels are supported: the
current LTS kernel and the previous year's LTS kernel.

But during the winter only one kernel is supported.

From the kernel team's perspective they may even be able to leverage
SLE kernel support at all times because they will have to support SLE
kernels longer than the 12 months I'm proposing. That assumes the SLE
will be supporting each of the annual LTS kernels.

Greg, please consider the user impact of what you are proposing.

Two kernels in the same distro?
Users having to switch to one during the lifecycle of the distro?
That complexity and that forced changing brings with it risk - new kernels
break things for some people. Some people don't want to take those risks. Those
are the people we make Leap for.

Leap is never going to support the latest and greatest hardware. It's not meant
to. It's meant to be a reliable, dependable, workhorse of a distribution that
people can put their faith into.

A more moderate pace of change,like the one we currently have, is the best way
to accomplish that.

For people like you who buy USB 3.1 Gen 2 Ludicrous speed cards so early in the
protocols existence the Kernel doesn't support it yet, we have Tumbleweed.

You cannot have it both ways. If you want to leave life on the edge, and your
hardware purchases suggest you do, then Tumbleweed is the best platform for you.

And before you argue '3.1 Gen 2 is going to take over the world in 12 months,
I'd like to point out that USB 3 came out in 2008 and took years before
becoming ubiquitous.
3.1 is only just now appearing on new mainstream machines and even then that is
Gen 1, fully supported stuff
I can find ONE motherboard, a high end MSI gaming board with a Gen 2 card in it

We're not building Leap to cover every edge case. USB 3.1 Gen 2 is an edge case
now, it will be in November, and I do not feel it's support is a compelling
argument for playing loose and risk with the entire concept and purpose of what
we're doing with Leap.

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups