Mailinglist Archive: opensuse-factory (988 mails)

< Previous Next >
[opensuse-factory] Proposal: Leap Development Model & Package Version Guidelines
Now development Leap 42.1 is underway, I'd like to see the Project
firm up and document certain key processes, like the Leap Development
Model (aka "How the heck to get stuff in Leap?" and "What versions
should be in Leap?")

In this email I'm proposing the skeleton of a Model. I don't expect it
to be accepted without discussion before we add it to the Wiki as
'official process'

Prerequisite - a good understanding of the Factory Development Model (
https://en.opensuse.org/openSUSE:Factory_development_model ) is
probably necessary to understand what I'm suggesting here, as my
proposal has a lot in common with it.

====

Development Model:

Leap is built in it's own project (currently openSUSE:42) in the Open
Build Service. Development does not happen directly in this project,
but is expected to occur in one of 3 locations before being submitted
to openSUSE:42

These locations are:
1) SUSE:SLE-12:GA and SUSE:SLE-12:Update projects - These contain
sources from the SUSE Linux Enterprise distributions
2) Stable-Devel Projects - Devel Projects created for the specific
purpose of developing stable versions of a specific group of packages
(eg. GNOME, KDE)
3) openSUSE:Factory - Containing sources from the openSUSE Tumbleweed
rolling release

Stable-Devel Projects:
Each stable-devel project has its own set of processes, rules and
communication channels that fits them best. The reference point for
this information is the project description of their Build Service
project. Stable-devel projects are also subject to change because the
world of FOSS software is constantly evolving. Certain software
becomes obsolete, standards and defaults change. That means
stable-devel projects can change names, get dropped, be newly created,
or change content and direction, as can packages in stable-devel
projects.

In these respects Stable-Devel projects are very similar to Devel
projects for the Factory Development Process. In technical terms, they
are practically the same and use the same functionality in OBS.
Stable-Devel projects are just 'Devel projects for Leap' where as
plain Devel Projects are 'Devel projects for Factory'.

Stable-Devel is just a special naming convention for these Devel
Projects dedicated for Leap.

Stable-Devel projects are focused on the development of *stable
versions* for Leap, and not necessarily the latest upstream versions
which are likely to be contained in the Factory devel projects.

The use of Stable-Devel projects should easily enable teams like KDE
and GNOME to develop and maintain specific targeted stable versions
for openSUSE Leap, which may diverge from the latest upstream versions
present in Factory.

For the rest of the Leap Development Model, the process pretty much
mirrors the Factory one. Stuff gets submitted, staged, tested, and
released in the same way.

=====
Package Version Guidelines

openSUSE Leap aims to be a stable general purpose Linux operating
system, for both Desktop and Server workloads, with an emphasis on
Systems Administration, Developer and Advanced Desktop use cases.
This means, unlike Factory/Tumbleweed where package version criteria
is often a simple case of "it's new, it works, and someone is willing
to maintain it", in openSUSE Leap this decision making process should
be a little more nuanced.

Below are some general rules regarding which version should be
selected for openSUSE Leap

Rule #1 - The version from SLE-12:GA and SLE-12:Update should be
considered first

This rule is however not a hard and fast rule. There are both
technical reasons and potentially usability reasons for not adopting
the SLE-12 version of a package.

For example, hardware compatibility requirements may necessitate an
upgrade of the Linux kernel.
Software stacks like Desktop Environments might make sense to move
faster than the SLE-12 version in order to provide our openSUSE Leap
users with a still stable, but up to date desktop environment.
And it may be the decision of our contributors that a specific new
version of software might be significantly easier to maintain than the
version provided by SLE-12.

These are all valid reasons for considering making an exception to Rule #1

However the following should be remembered: _for each Package in Leap
that does not come from SLE-12, it requires high quality, sustained,
maintenance from it's openSUSE package maintainer_

Leap users expect high quality packages with safe, secure, software
updates, so Package Maintainers should be aware of their
responsibilities before committing a package version to openSUSE Leap.

Rule #2: Leap should only contain software that is considered 'Stable'

Software that is considered Alpha or Beta quality should not be
considered for openSUSE Leap.
Users expect Leap to contain software they can rely on.

The decision of the level of quality & stability of each Package is
the responsibility of our Package Maintainers.
They have the right to 'overrule' the declared Alpha/Beta quality
status of their Upstream package if they are confident they know
better and/or they are mitigating the potential problems to our users
somehow.

Rule #3: Long Team Stable (LTS) versions should be preferred, if they exist

Some software, like the Kernel, may have long term stable versions
which are maintained by their upstreams for a long while.
This makes perfect sense for Leap, so if Rule #1 does not apply, these
LTS versions should be considered as strong candidates for inclusion
into Leap.

Rule #4: Upgrading to the latest version is not always the answer

Unlike Tumbleweed, we don't always need to upgrade to the latest
version of every software stack in every minor version of Leap.

If rules #1, #2, and #3 have been followed, then it is entirely
possible that the right choice of version for the next minor release
of Leap is 'the version we already have'
This is a good thing and shouldn't be frowned upon.

Remember, users have Tumbleweed if they want everything new all the
time, and users will still see all of this in the next Major release
of Leap when it comes around.
====

As you can tell from these rules, none of them are hard rules which
must be followed to the letter. They hopefully set out the general
scope and direction of what Leap is trying to achieve, and it is the
responsibility of Package Maintainers to make informed decisions based
on the realities of their packages upstream development model and
their individual time and ability as Package maintainers to maintain
stable software.

Thoughts, Comments, Flames, please ;)

Regards,

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

< Previous Next >