Use the scroll wheel to zoom. When zoomed, click and drag to pan.
Double click in the Roles and in the Boxes to get more information.
This workflow provides two entry points (blue boxes) and two valid exit points or final products (red boxes).
The current workflow is included in this proposal, and is marked using thicker lines.
A package is usually developed in a Home Project. We can consider it as the starting poing for this workflow, together with the Devel Project Integration task.
With OBS, a contributor can make a local branch (usually from a Devel Project) of the package to start working on it. Once the developer finishes with the package, he creates a Submit Request to send it back.
This is usually how packages are being developed: They start in home project, move to devel project and continue to Factory.
A Submit Request is a request of integration from one project to another. This object also captures all the changes made in the package, with some of the meta information related with this petition (history of approvals, current status, etc).
If the developer wants to include the updated version of the package, she / he needs to create a formal petition via this SR. We also have policies that describe what extra actions need to be done when the developer wants to add a new package to Factory.
The Project Maintainer can decide whether to accept or reject the SR according to rules described in external policies.
This decision is expressed via OBS and usually the rejection is justified in order to give the submitter some feedback and a chance to submit changes again.
The integration can be defined as the process of merging all packages together in a single tree, creating a consistent whole inside the Devel Project.
This integration can have two different origins:
The Package Maintainer can also work on her / his own package without the Project Maintainer intervention.
Create the SR (or group of SR) to be integrated into Factory.
The osc-legal.py bot checks if the package referenced in the SR had a compatible license or if this package was previously approved. If none of these conditions are met, the bot can reject the SR and wait for a manual review later in the process.
rpmlint runs as part of the package build. The review bot makes sure that there are no overrides of rpmlint rules that bypass policies
There is an automatic technical review process for every new SR to Factory. This review checks for potential problems before the integration, like expanding the Base: System, disabled repositories, new version of the packages or introducing cycles in the dependencies
Some packages (or groups of packages) need more effort to be integrated into Factory. For example, a new update of GCC may demand some work to other packages that do not compile using the new compiler without modification.
For those packages it's a good idea to 'fork' Factory, integrating an initial version of the new package (GCC in the example) together with all the affected packages. Now the developers can work on the integration of all those components. This is the main reason of the staging project.
But someone needs to make a decision about the kind of projects that need a staging project, because the creation of a staging project from scratch is expensive. To avoid the waste of resources, one possible solution is creating a pool of staging projects that can be assigned and prepared by the Technical Reviewer. In case of necessity the Factory Maintainer can create new staging projects.
Staging Projects is one of the most important changes proposed for the new workflow. Staging project is assigned by the Technical Reviewer for packages that can affect multiple other packages. For example: GCC, Autotools, systemd or maybe NetworkManager are good candidates for a Staging Project.
So, they start as a submission to Factory that is deemed to require a Staging Project, or that is part of an already existing request. The Staging Project has a single maintainer (similar to a Project Maintainer) and multiple developers or contributors. The contributors can create SRs to this Staging Project, but only the Project Maintainer can create the SR that goes outside the Staging Project.
The Staging Project is developed on a specific branch of openSUSE:Factory, and is used to fix the issues related with this package.
The Project Maintainer for this Staging Project is the only one that can create a group of SRs to Factory (or, as we will see, to comeback to the Devel Project). The group of SRs needs to be managed as a transactional unit: accepted or rejected as a whole. This transactional nature avoid problems related with changes that only have meaning when they are grouped together.
Some SRs from the Staging Project can continue on their way to Factory, but some of the changes can comeback to the Devel Project (or group of Devel Projects). The rationale behind this is to avoid (or at least mitigate) the so called 'merge problem'. This problem happens when the version of the package that we find in Factory in not exactly the one that was sent in the original SR from the Devel Project, and the version of the Devel Project was updated after the SR (but before the integration into Factory). If you are a Project Maintainer or a Package Maintainer you know what I mean with this: there is not a clear way in OBS to make a merge different from a fast-forward one.
There are some packages, like the Linux kernel, that are good candidates for automatic testing before the integration into Factory. Good candidates are packages that can put the system in a very unreliable situation (for example, they can't boot anymore or can disable the access to the network).
In this task the Technical Reviewer needs to identify such packages in order to demand a pre integration test from the QA Team.
Process to check whether it's safe enough to integrate a set of changes into Factory. We plan to update openQA and make a more stable tool that can help the QA team to automatize this king of pre-Integration tests. With this task we can discard bad updates that can compromise the full system, and guarantee that at least what is in Factory provides a minimum functionality to the user.
During the legal review the package which didn't pass the automatic checks is inspected by the legal reviewer. It is verified that the proclaimed licence matches the code, it is distributable and there are no infringements or patents involved.
rpmlint runs as part of the package build. The review bot makes sure \ that there are no overrides of rpmlint rules that bypass the policy. If there is any problem, the Security Reviewer can help the developer to review manually the package and provide advice to fix the policy violation.
Technical review is formal verification that the submission is up-par with regards to all the formatting norms for changelog and spec files.
During the review the code is also verified not to contain any unforeseen consequences.
The process of merging all packages together in a single tree, creating a consistent whole in Factory. The right time for integration needs to be planned based of availability of resources to keep the performance of the overall building process within acceptable parameters.
Continuous process to ensure that Factory is solid enough to be used in a daily basis by contributors and for creating Factory-Tested and the ISOs. The process includes periodical checks of the overall Factory status, reverting or removing packages causing troubles, notifying issues with packages to the responsible people, maintaining the XML files used to generate ISO images and the patterns needed for installation and other related tasks.
Integration tests are done by QA Team when a new SR is integrated in Factory and needs to be tested before passing to Factory-Tested. When the Factory Maintainer integrates a new SR, there is a good possibility that some part of the system stops working. The Integration Test is designed to assure that the integration of a new package doesn't affect the functionality of a different package in a unnoticed way.
To provide this, QA Team will run a set of transversal tests along the full distribution, to make sure that the system works similar to how it worked before integrating the SR.
This task also decides if the new SR that comes from Factory goes to the next step until Factory-Tested. If QA Team detect an important issue related with the new SR, they can decline the copy of the new package (or group of packages) to Factory-Tested.
The Integration Test task can detect errors in the distribution, and as a result of that QA Team needs to fill a bug report. This bug report needs to be precise and detailed to make easy the work for the developer.
Sometimes the bug reported needs to be tracked to avoid regressions. In this case the QA Teams also needs to add a new test case in the tool to detect them.
This is the stable version of Factory. The final product for most users. Still, those wanting to try more recent package versions can install the bleeding edge version of Factory used for integration.
From time to time the Coordinator can decide if the quality of the installation part of Factory is good enought to make an ISO snapshot of the distribution.
This image will be the recommended medium to install the distribution.
Factory snapshot used to install the distribution.
The person for this role will be one individual selected from the Factory maintainer role.
Previously this role was more broad and with more tasks. But due to the automation in place the Coordinator will be just responsible for reviewing the ISO after all previous steps were completed.
Reviews submissions to Factory to make sure they follow packaging guidelines and don't contain obvious errors.
Newly technical reviewer also groups packages related to each other (think new KDE) that are going to get accepted all together.
He/she also decides, when the change might have a big enough impact to run it through staging project first (new autotools, boost, gcc, icu, ...) or when the change is big and might seriously break things for people in runtime so it needs to pass through openQA (think new Xorg, new systemd, ...)
Team of people who watch over automatic tests and try to maintain them and adjust them whenever needed.
This team is working on expanding openQA and its coverage.
Reviews submissions to the devel project and pushes them forward if they're approved. Almost always also package maintainer.
Project maintainer can be also maintainer of a temporal staging project that gets created when some major change is on its way to factory. Here he has to fix packages/ping package maintainer to fix packages and propagate them back to the devel project.
Somebody who creates, fixes or changes individual packages, probably will overlap with project maintainer in quite some cases.