openSUSE:Factory development model
Development Model
Factory is built in its own project openSUSE:Factory on the Open Build Service reference server.
As you can see, it is a huge repository of packages. Development, however, does not happen directly in openSUSE:Factory but in so called devel projects.
A devel project, as the name suggests, is a project where development happens for a specific group of packages, like multimedia, GNOME, KDE or Kernel.
The relation between packages in the openSUSE:Factory project and packages in the devel projects is expressed in the meta data of the packages inside openSUSE:Factory.
Devel Projects
Each 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.
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 devel projects can change names, get dropped, be newly created, or change content and direction, as can packages in devel projects. The current devel projects feeding into factory can be found on this page.
You can find a summary description of the Factory submission process here.
You can check a more detailed information about this topic.
Staging Projects
Once in a while, a specific core package (like a new version of GCC) is deemed to have the potential to break so much that the Factory Maintainers decide to create a special staging project in which every package of Factory is built against the new package. Its developers can then fix the resulting breakage before integration back into Factory.
Staging projects can be seen as a fork of Factory in which some developer can prepare changes/updates to different packages, build them together, test them and submit them together for inclusion into Factory when everything has been tested successfully.
Submit requests to Ring 0 and Ring 1
The core of Factory is divided into two rings (0-Bootstrap, 1-MinimalX). Ring 0 contains packages that form the most basic, minimalist system that can compile itself. On top of that Ring 1 adds what's in the default installation of the two primary Desktops. All other packages are not part of a ring.
When a submit request is done to a package that belongs to any of the rings, the request is automatically put in a backlog for the Staging Master to review and assign it to a specific staging project.
There a number of staging projects (A, B, C, ...) which purpose and contained packages change over time. An ISO installation image is generated for each Staging Project regularly, and this image is tested on openQA, in order to verify that those packages would not break the current Factory.
It might be possible that other packages fail due to this submit request, in that case, those packages are added to the same staging project, so they're built against each other.
Once every package in a Staging Project builds successfully and the openQA tests are successful, the Factory Maintainer can submit it to Factory and leave the Staging Project free to test other changes in the future.
ADI Projects
There is also another kind of Staging Projects: ADI Projects (ADI is an acronym of Ad Interim). These are temporary projects created for submit requests of packages that do not belong to any ring.
The main differences with a regular staging project are:
- only packages contained on the ADI Project are built (inherited packages are not rebuilt)
- only buildability is checked (no openQA tests).
ADI Projects are named with :adi:NUMBER instead of a letter (e.g., openSUSE:Factory:Staging:adi:12).
Tools used
- osc-plugin-factory is the tool that handles everything related to Staging Project.
- This staging plugin document explains the usage of this tool.
Minimizing package builds
By default, when a package is updated in OBS all depending packages are rebuilt (see see Build Service Scheduling Strategies). That's indeed the case for the Tumbleweed images. But rebuilding the packages in the software repositories so often would cause constant updates for already installed Tumbleweed systems without really bringing new versions of the software.
To limit that, the Tumbleweed repositories are configured to build only the updated packages and not those that depend on them (ie. the build trigger setting is set to "local"). An OBS bot (part of the repo-checker suite) checks when that causes problems in a depending package and triggers a rebuild to fix it. The Factory maintainers can also trigger rebuilds manually if a similar problem is overlooked by the bot but detected by any other mean.
Development Process Overview
The complete Development Process is detailed on this page. It consists of the following steps:
- Roadmap and Feature Planning is managed by the Release Manager who creates the initial roadmap. Meanwhile, the developers set technical goals for the distribution based on the projected release and freeze dates.
- Package Development starts in a OBS home project [8]. The Package Developer can work here without affecting anything else. Once the package is good enough a submit request to a devel project can be created.
- Devel Project Integration follows, overseen by Project Maintainers who keep an eye on the technical quality of submit requests and the overall state of a Devel Project. After successful integration, the Project Maintainers create Submit Requests for Factory.
- The Review Process makes sure that all packages on their way to Factory go through 4 (sometimes 5) reviews:
- Factory-Auto: a script that checks basic rules [10]
- Legal-Auto: a script checking if the license of the package is in the permitted license database; if not found in the DB, the review stays open until a human adds the package to the database[10]
- Repo-Checker: a more in depth (and slow) automatic check [10]
- Review Team: human check of the request.
- Optional: Manual Security Team check (if Legal-Auto deems that necessary)
- Factory Integration is overseen by the Factory Maintainer and the Release Managers who accept the submit requests that come from the different devel projects to Factory [9]. They mostly decide based on timing and policy factors like freezes that might be in effect as the review process has already taken care of quality. In some cases, they decide a Staging Project is needed. When a Staging Project is needed, the submit request needs to walk through openQA and must be have green result. Once everything goes fine, the Factory Maintainer would accept that Staging Project so all the submit requests that belong to that Staging Project will be checked into Factory.
- The Quality Assurance Process (openQA) runs all the time. Periodically, ISO images are generated by OBS and ran through a predefined set of tests. If problems are found a report is created pointing to the failures in that ISO image. Currently, openQA is mainly testing Staging Projects and Factory-ToTest images.
- Factory-ToTest. In the current Factory model, Factory-ToTest represents the project that stores several Factory Snapshots that are candidates to be released if the quality was good enough on openQA.
- Release Process. Based on timing and the results of the QA process, a milestone or beta can be released by the Release Manager. He/she takes care of the release tasks: calculate the ISO MD5/SHA1 hashes, set up the repositories, prepare and seed the mirrors, deploy the products and kick marketing to communicate the release.
- Public Testing takes place after the milestone release, usually on real hardware and to a lesser degree in virtual machines.
Not too long after the release of the Beta (the final milestone before total freeze), the Release Team forks off the release from Factory and uses the Maintenance update process to stabilize the release.
- You can check a more detailed information about openSUSE Development process.
- Find out more about the release process here.
- Find out what is what in the Glossary.
Governance Model
Bug fixes and new features have to be first committed to a devel project, and from there will be forwarded to the main openSUSE Factory project. Because of this, the governance of the Factory project is also further broken down.
Responsibilities
| Package | Devel Project | Factory |
|---|---|---|
| Maintainer & Bugowner | Project Maintainer & Bugowner | Release team |
See a more detailed list of roles and responsibilities here.
Escalations
Most decisions are taken by the maintainer of the package. If the maintainer cannot take a decision, or if a conflict arises between maintainers, the devel project maintainers decide together. If the devel project maintainers also do not come to a conclusion, or a conflict between two devel projects arises, the openSUSE release team takes the decision. If the decision cannot be taken by the release team, they appeal to the openSUSE Board which tries to facilitate the decision with all the involved people. If that also is not successful, the board puts up the issue to a vote among the members.
Maintainer ==> Devel project maintainers ==> openSUSE:Release team ==> openSUSE:Board ==> openSUSE:Members Vote
You can read a more detailed information about the openSUSE/factory Development process.