On 27 July 2015 at 16:30, Richard Brown wrote: Stable-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.

I want to give a real-world example of how I see this working Right now we have GNOME:Factory as the Devel Project for GNOME in Factory at this very moment, there is no need for a GNOME Stable-Devel project as the packages for Leap are coming from Factory However, months from now, GNOME will jump to 3.18 in Factory and this may not be the version we put into Leap This will mean Leap will need a Stable-Devel project for GNOME to handle the development of 3.16 in Leap. This Stable-Devel project for GNOME will probably be called something like GNOME:Stable:3.16 - which actually already exists (that was part of the point of this concept, I wanted to have it easy to layer on what teams like our KDE and GNOME team are already doing) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/27/2015 04:30 AM, Richard Brown wrote:

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

I would add to this the Backports project. Yes, there is an implicit overlap as things in backports are supposed to come from a Devel project or Factor/TW, but I think it is worth mentioning the Backports project to avoid unnecessary confusing and implicit assumptions.

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

Team -> Term ?

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. ====

The TW comment should be removed, it is not related to the "Guidelines for Leap development"

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 ;)

I think most of the explanatory comments should be removed from the main body of the guidelines and covered separately, or the other alternative is to list the 4 primary guidelines first without much extra explanation and then re-list them with the more detailed explanation, for example: """" General guidelines: 1.) Whenever reasonable The version from SLE-12:GA and SLE-12:Update should be considered first 2.) Leap should only contain software that is considered 'Stable' 3.) Long Term Stable (LTS) versions should be preferred, if they exist 4.) Upgrading to the latest version is not always the answer 1.) Whenever reasonable The version from SLE-12:GA and SLE-12:Update should be considered first + blah blah blah 2.) Leap should only contain software that is considered 'Stable' + blah blah blah .... """" Overall, while I was reading the proposal it started to feel very restrictive and not very exiting to contribute to. Thus, some re-wording and simplification may be a good idea. There were more "don't do that" implications than "get cracking and help" ;) Later, Robert - -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVtpc9AAoJEE4FgL32d2UkcA0H/3kBMKsMSFSPSQ33X7O5tLTa sbLrZbhJO5XryGoqXwSH5zCBgCJLrGrREb3V+PDYnprze9YYLofOvy7qF4naa4xE SiyrN25vztYX6PoFd/S4IYEwwofm9tdqJKcgYvHPMHW+VdrUgmkpv/WruLS0AqEr eJ9IQO+WWlx12KLqJ9y4fZE3T9eWMYr4chIkWSXGv/5uUH+SQ8+8rGu3C7vAglGG 20UydhfhAjxZR1KLSXes1FAmTxp5Alk0TiSZktZUcrVJmNYcjps0wjiZgm8U5QuB lJ4gM+wWDZV/4VmNBoFfiPVxud061NGni/IdeEdBrDiLwzPNkNTSzQMc1pjuQt8= =7fSG -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org