On Tue, 2020-04-14 at 17:57 +0200, Vojtěch Zeisek wrote:
Dne úterý 14. dubna 2020 16:11:20 CEST, Michal
On Tue, Apr 14, 2020 at 03:59:49PM +0200, Carlos
E. R. wrote:
On 14/04/2020 15.53, Johannes Kastl wrote:
On 14.04.20 at 15:20 Gerald Pfeifer wrote:
> > As an aside, Jump is an awful name, since it's a way too
> > common of a
> > word in the English language to build any reasonable
> > branding around
> > it.
> Isn't Jump more like $JUMP, its actual name to be determined?
We should decide on a sensible name very soon, otherwise Jump
mentioned in dozens of places already... :-(
I think it is a very bad idea to change names, Yet another Time.
I think this is not to change name, rather to refer to the SLE
Leap while it exists alongside the Leap as it is built now.
I don't really see a problem with Jump as a name for such temporary
If the plan is something like Leap 15.1 -> Leap 15.2 -> Jump 15.2 ->
15.3/16.0 (if I get it correctly), why not rather something like Leap
Leap 15.2 -> Leap 15.2.1 -> Leap 15.3/16.0?
There are two options on the plate.
But first let's make sure that it's clear that we will not support two
openSUSE Leap based distributions in parallel at least not for primary
Arches (RISC-V, armv7 might be different stories).
The goal is to reduce effort, not to double it!
What's really Jump?
Jump is under name "jump" only a tech preview / prototype, which is
subject to further research. It's not a supproted upgradable
product/project from 15.1 or 15.2. Nobody blocks you to migrate to the
tech-preview, we'll be happy for an extra testing, but it's
unsupported. In the end we will have to do some heavy testing on all
kinds of migrations, as one of goals is seamless migration to SLE.
So back to options
Option (1) - All goes well (prototype is accepted well, all works as
expected). We Start setting up Leap 15.3 Alpha in later summer.
openSUSE 15.3 Alpha is already based on the new Jump build workflow.
openSUSE 15.2 mainteinance stays untouched. Leap 15.2 is
discontinued/unsupported 6 months after 15.3 is releases.
Option (2) - Same as (1) + But at some point in time we will rework
15.2 updates to be build in a way like the new openSUSE Leap 15.3 Alpha
. openSUSE Leap 15.2 receives a maintenance update which will be
released together with install image refresh "aka" intermediate release
I'd really vote for as seamless-as-possible upgrade or even update if
possible (let's see how research goes). A lot of packages would be
replaced due to vendor changes. This would most likely happen somewhen
in Autumn. Perhaps we will really have to use 15.2.1 in case that 15.2
itself would not be upgradable to SLE (again let's see how research
goes). But I believe we already claim that user is expected to install
all available updates.
Option (3) - Everything goes bad, protoype is not accepted well and we
keep Leap as it is, but at least we were able to align SLE and Leap
Resource-wise (2) is the best option as we can finally focus just at
"one" openSUSE Leap build workflow alredy in late Summer/Autumn and
save a lot of duplicity on keeping both operational. 12 months is
really a lot of time.
I'd still like to see Jump operational before we decide to flip the
Release Manager openSUSE Leap
SUSE Software Solutions Germany GmbH
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer