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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org