[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@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 July 2015 at 16:30, Richard Brown <RBrownCCB@opensuse.org> 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
Hello, On Jul 27 16:30 Richard Brown wrote (excerpt):
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'.
I fear that naming may lead to confusion. Up to now there have been only one kind of development projects and therefore they can be called simply "Devel Project". Now there are two kind of development projects. I think they should not be called "Devel Projects" and "Stable-Devel projects" because it will be confusing when nothing has now a meaning (<no_prefix> means "Factory"). I suggest to be explicit to avoid ambiguity and call them "Factory Devel Projects" and "Leap Devel Projects" When using "Devel Project" (without prefix) any kind of development project is meant. This will be even future proof for possible third or fourth kind of development projects. The name "Foo development project" or "Foo devel project" will mean what the output of $ osc develproject openSUSE:Foo <package> is. But there is no (not yet?) openSUSE:Leap. Accordingly it would have to be called "42 devel project". "Leap" == "42" == "Stable-Devel" == <whatelse>? Personally I do not care how it is called. I will (have to) learn the wording whatever it is. I only wonder if it might be confusing for new contributors? Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 27, 2015 at 3:11 AM, Johannes Meixner <jsmeix@suse.de> wrote:
On Jul 27 16:30 Richard Brown wrote (excerpt):
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'.
I fear that naming may lead to confusion.
Up to now there have been only one kind of development projects and therefore they can be called simply "Devel Project".
Now there are two kind of development projects. I think they should not be called "Devel Projects" and "Stable-Devel projects" because it will be confusing when nothing has now a meaning (<no_prefix> means "Factory").
I suggest to be explicit to avoid ambiguity and call them "Factory Devel Projects" and "Leap Devel Projects"
or to take this opportunity to reduce the Factory == or <> Tumbleweed confusion "Tumbleweed Devel Projects" and "Leap Devel Projects" after, of course, moving some block of Factory resources into a Tumbleweed named space and proceeding to develop and release Tumbleweed under its own name rather than its former Factory name. Or will the Factory name be surviving for some purpose?
When using "Devel Project" (without prefix) any kind of development project is meant.
This will be even future proof for possible third or fourth kind of development projects.
The name "Foo development project" or "Foo devel project" will mean what the output of $ osc develproject openSUSE:Foo <package> is.
But there is no (not yet?) openSUSE:Leap. Accordingly it would have to be called "42 devel project". "Leap" == "42" == "Stable-Devel" == <whatelse>?
Now that the name Leap is official, isn't it time to move 42 to Leap-42.1 so we can discuss the project under its official name and version and find it there in the Open Build System? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.07.2015 um 22:13 schrieb PatrickD Garvey:
Now that the name Leap is official, isn't it time to move 42 to Leap-42.1 so we can discuss the project under its official name and version and find it there in the Open Build System?
No, the devel projects will be for the code stream - which would be openSUSE:Leap. And we would fork this for the actual release to openSUSE:Leap:42.1, but don't do development in there, but cherry-picking to fix critical bugs. The move from openSUSE:42 to openSUSE:Leap has to happen somewhen, but it's really a lot of work, so I would prefer to do this only after 42.1 Greetings, Stephan -- Ma muaß weiterkämpfen, kämpfen bis zum Umfalln, a wenn die ganze Welt an Arsch offen hat, oder grad deswegn. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 27, 2015 at 6:43 PM, Stephan Kulow <coolo@suse.de> wrote:
Am 27.07.2015 um 22:13 schrieb PatrickD Garvey:
Now that the name Leap is official, isn't it time to move 42 to Leap-42.1 so we can discuss the project under its official name and version and find it there in the Open Build System?
No, the devel projects will be for the code stream - which would be openSUSE:Leap. And we would fork this for the actual release to openSUSE:Leap:42.1, but don't do development in there, but cherry-picking to fix critical bugs.
The move from openSUSE:42 to openSUSE:Leap has to happen somewhen, but it's really a lot of work, so I would prefer to do this only after 42.1
Greetings, Stephan
Since I can't yet do the work for you, I have to respect your decision. It is one of those "Pay me now or pay me later." situations, though. Respectfully, PatrickD -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 28 July 2015 at 04:13, PatrickD Garvey <patrickdgarveyt@gmail.com> wrote:
or to take this opportunity to reduce the Factory == or <> Tumbleweed confusion
"Tumbleweed Devel Projects" and "Leap Devel Projects"
after, of course, moving some block of Factory resources into a Tumbleweed named space and proceeding to develop and release Tumbleweed under its own name rather than its former Factory name.
Or will the Factory name be surviving for some purpose?
This thread is primarily to discuss the development of Leap - the naming of the Factory OBS Project is quite a way out of topic But to restate this for the record Factory is the Project where Contributors contribute stuff intended for Tumbleweed. After it's tested, it's released to users under the marketing/brand name, Tumbleweed Because of this distinction, the 'old name' of Factory still serves a purpose, and while I can accept there may be some benefit of retiring the name entirely, I'd vote for doing one thing at a time Developing a new kind of distribution is probably enough to keep us busy right now ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Jul 27, 2015 at 6:55 PM, Richard Brown <RBrownCCB@opensuse.org> wrote:
On 28 July 2015 at 04:13, PatrickD Garvey <patrickdgarveyt@gmail.com> wrote:
or to take this opportunity to reduce the Factory == or <> Tumbleweed confusion
"Tumbleweed Devel Projects" and "Leap Devel Projects"
after, of course, moving some block of Factory resources into a Tumbleweed named space and proceeding to develop and release Tumbleweed under its own name rather than its former Factory name.
Or will the Factory name be surviving for some purpose?
This thread is primarily to discuss the development of Leap - the naming of the Factory OBS Project is quite a way out of topic
But to restate this for the record
Factory is the Project where Contributors contribute stuff intended for Tumbleweed. After it's tested, it's released to users under the marketing/brand name, Tumbleweed
Because of this distinction, the 'old name' of Factory still serves a purpose, and while I can accept there may be some benefit of retiring the name entirely, I'd vote for doing one thing at a time
Definitely with the size of the staff available, doing one thing at a time is a step towards quality.
Developing a new kind of distribution is probably enough to keep us busy right now ;)
Thank you for taking the time to address my suggestion. Respectfully, PatrickD -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 27 July 2015 at 18:11, Johannes Meixner <jsmeix@suse.de> wrote:
Hello,
I suggest to be explicit to avoid ambiguity and call them "Factory Devel Projects" and "Leap Devel Projects"
When using "Devel Project" (without prefix) any kind of development project is meant.
Agreed, this suggestion makes perfect sense and fits in better with how the Devel Project functionality works in OBS - Devel Projects can exist to point to other Projects, not just Factory, so using Factory Devel Projects and Leap Devel Projects as the naming scheme makes more sense than the current where we always assume Devel Project == Factory Devel Project.
But there is no (not yet?) openSUSE:Leap. Accordingly it would have to be called "42 devel project". "Leap" == "42" == "Stable-Devel" == <whatelse>?
I'll let Coolo comment on this, openSUSE:42 is his project to fix ;) -- 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
participants (5)
-
Johannes Meixner -
PatrickD Garvey -
Richard Brown -
Robert Schweikert -
Stephan Kulow