Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
[opensuse-factory] Re: How Leap and SLE's timetable overlap
On Wed, 25 May 2016 00:38, Richard Brown <RBrownCCB@...> wrote:

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 42.2

* 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 together..yeah..um..sorry 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

@Richard: There was no critic to the approach / schedule
we use now intended.

This is but a try to feel out, if there is a possiblity to get
Leap out earlier in the year / nearer to the LTS kernel release.

Playing it through, I got very soon to the point that a April
release for Leap and a October release for SLE (Hello Ubuntu),
will simply not work for us here at (open)SUSE.

Trying other variants, comparing these to past experiances,
the propsal above was the only one where I got to a Leap
before main summer vacation and still a hefty benefit for
the SLE team. It was the best of ca. 30 or so tries.

And only possible because of Tumbleweed doing the heavy-lifting
beforehand (Kernel-, compiler-, tool-chain- upgrade, full rebuild).

Still, for up comming release a full support for the Intel
Skylake cpus, esp. the IRIS 550 / 580 gpus should a fix-point.

That will need some, for the 4.4.0 missed out / forgotten patches
for the kernel, and Mesa 11.3 (will come June) at minium.

If we can lobby for some more drm / amd / nouveau / late fixes backport,
we all will benefit, but IMHO this has to happen upstream.

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

< Previous Next >
References