openSUSE:Development Process
openSUSE Development and Integration Process
From Roadmap to Beta1
Version 1.1.0 - 25/09/2013 Author: openSUSE Team at SUSE
About this document
Draft document edit
Warning: This draft document is a work in progress; it may not represent the entire picture of the development process. The community is currently reviewing it.
Goal of the documentation
The openSUSE Integration Process, known as Factory development, is a complex software development process which involves hundreds of developers all over the world and lasts usually between 5 and 7 months.
The goal of this document is to:
- Serve as main reference to the existing documentation around the process.
- Provide the big picture of the process to those potentially interested in joining.
- Help us to detect areas for improvements.
Process followed
The process followed to create the document has been:
- Collect and analyze existing documentation and references. (See References at the end of the document).
- Create a high level work flow during a session with the openSUSE team.
- Use ETVX [13] methodology to describe the process.
- Create a WBS out the ETVX outcome.
The creation of the document is done in iterations:
- Analysis and redaction by openSUSE Team at SUSE.
- Feedback from SUSE employees involved in openSUSE and managers.
- Feedback from openSUSE contributors (Factory/devel projects mostly).
Document structure
The document describes the process following a top-to-bottom approach. It provides first a high level overview (Section 2) complemented by a more detailed description of every activity (Section 3). On Section 4 the roles and teams involved in the process are explained. Finally the document includes a glossary of terms (Section 5) and many references to further information (Section 6).
This document do not cover all the insides of the process since it is too complex. In order to create a detailed WBS it is needed a deeper analysis.
Previous work
There is a previous effort about documenting the development process, focused in how Factory works. You can find this version here https://en.opensuse.org/openSUSE:Factory_development_model
Feedback
To provide feedback please contact Alberto Planas (aplanas@suse.com) or any other member of the openSUSE Team at SUSE.
Development and Integration process Overview
ETVX Summary
This section introduces the general view of the development and integration process. This flowchart show a very general view of the full process. Every action of this process are described briefly here in this section, and with more details using ETVX tables in next sections.
| Roadmap and Feature Planning | |||
| E1.1 | Previous release version of the distribution was released | ||
| T1.1 | Create the roadmap description | Release Manager | |
| T1.2 | Feature freeze calendar | Release Manager | |
| T1.3 | Determine the new features | Project MaintainerPackage Maintainer | |
| V1.1 | Review the roadmap | Product ManagerRelease Manager | |
| V1.2 | Roadmap maintenance | Release Manager | |
| X1.1 | The roadmap and the freeze calendar are published in the mailing list | ||
| D1.1 | XML Document with the roadmap | ||
| D1.2 | Features documented in openFATE and in the wiki | ||
| Package Development | |||
| E2.1 | Developer creates a new package not in Factory or in devel project | ||
| E2.2 | Developer wants to update a package that is currently in the distribution | ||
| E2.3 | Bugzilla report | ||
| E2.4 | OBS / Hermes message | ||
| T2.1 | Create local package | Package Developer | |
| T2.2 | Branch package | Package Developer | |
| T2.3 | Fix / Update Package | Package Developer | |
| T2.4 | Submit to Devel Project | Package Developer | |
| T2.5 | Automatic Submit | Package Developer | |
| V2.1 | Is in Factory | Package Developer | |
| V2.2 | Automatic checks complete successfully | Package Developer | |
| X2.1 | Developer creates a submit request in OBS | ||
| X2.2 | Developer drops the change, aborting the development process | ||
| D2.1 | Submit Request | ||
| Devel Project Integration | |||
| E3.1 | A submit request from a Package Developer to a devel project | ||
| E3.2 | Project Maintainer wants to make changes to a package directly in the Devel Project | ||
| T3.1 | Integrate the submit request | Project Maintainer
Package Maintainer | |
| T3.2 | Package checkout | Project Maintainer | |
| T3.3 | Fix / Update Package | Project Maintainer
Package Maintainer | |
| T3.4 | Submit to Factory | Project Maintainer | |
| V3.1 | Review of the submit request | Project Maintainer
Package Maintainer | |
| V3.2 | Compile in OBS | Project Maintainer
Package Maintainer | |
| V3.3 | Automatic Security Review | Security Reviewer | |
| X3.1 | Package Maintainer creates a submit request for Factory | ||
| X3.2 | Package Maintainer acts as Package Developer and branches the package in a home project | ||
| D3.1 | Submit request to Factory | ||
| Review Process | |||
| E4.1 | A submit request is created by a Project Maintainer for Factory | ||
| -- | -- | ||
| V4.1 | Legal Review | Legal Review | |
| V4.2 | Factory Auto Review | Factory Maintainer | |
| V4.3 | Technical Review | Technical Reviewer | |
| V4.4 | Check Repo Review | Factory Maintainer | |
| X4.1 | All the reviews are positive | ||
| X4.2 | There is a negative review | ||
| D4.1 | Status of the submit request | ||
| Factory Integration | |||
| E5.1 | Submit request reviewed | ||
| E5.2 | The Factory Maintainer decides to fix an issue inside Factory | ||
| T5.1 | Monitor Factory | Factory Maintainer | |
| T5.2 | Maintain XML files used by OBS to generate ISO images | Factory MaintainerRelease Manager | |
| T5.3 | Integrate the submit request | Factory Maintainer | |
| T5.4 | Revert or remove packages | Factory Maintainer | |
| T5.5 | Issue notification | Factory Maintainer | |
| T5.6 | Create staging projects | Factory Maintainer | |
| T5.7 | Create Patterns | Factory MaintainerRelease Manager | |
| V5.1 | Is Factory open for submissions? | Factory MaintainerRelease Manager | |
| V5.2 | Brief review | Factory Maintainer | |
| X5.1 | Package is integrated in Factory | ||
| X5.2 | Package is declined and an event is generated in Hermes | ||
| X5.3 | A bug report is created in bugzilla | ||
| D5.1 | Package integrated into Factory | ||
| D5.2 | A building Factory repository | ||
| Quality Assurance Process | |||
| E6.1 | There is a new automatic build generated by OBS | ||
| E6.2 | Release Manager / Factory Maintainer test a new build image | ||
| E6.3 | The QA team has decided to test a new feature or reproduce a bug reported in bugzilla | ||
| T6.1 | Create a new test | QA Reviewer | |
| T6.2 | Test maintenance | QA Reviewer | |
| T6.3 | Create bug reports | QA Reviewer | |
| V6.1 | Test review | QA Reviewer | |
| X6.1 | Important / critical test are green. The ISO is candidate for release | ||
| X6.2 | Important / critical bug is detected. The ISO is rejected | ||
| D6.1 | Test report | ||
| D6.2 | Bug report | ||
| Release Process | |||
| E7.1 | It is 2 days before the chosen release date | ||
| T7.1 | Adjust and communicate new roadmap | Release Manager | |
| T7.2 | Build Images | Release Manager | |
| T7.3 | Generate signatures | Release Manager | |
| T7.4 | Calculate the ISO MD5/SHA1 hashes of the images | Release Manager | |
| T7.5 | Generate differences between current and previous milestone | Release Manager | |
| T7.6 | In case of Beta, release manager branches all the sources in Factory off | Release Manager | |
| T7.7 | Create announcement based on diff | Marketing Manager | |
| T7.8 | Sync the image and binary repository to the mirrors | Release Manager | |
| T7.9 | Enable the new milestone as a product in the Novell Product Page in bugzilla | Release Manager | |
| T7.10 | Publish release announcements | Marketing Manager | |
| V7.1 | Use openQA to check if the release is good enough | Release Manager | |
| V7.2 | Go / NoGo meeting if Beta 1 | Release Manager | |
| V7.3 | Check delays | Release Manager | |
| V7.4 | Check images synced and published | Release Manager | |
| X7.1 | Release is available and announced | ||
| D7.1 | ISO images for all supported platforms and architectures | ||
| D7.2 | Release announcement text for news.o.o and mailing lists | ||
| D7.3 | In case of delay: announcement and new roadmap | ||
| Public Test | |||
| E8.1 | A new release (Milestone or Beta) is published in sofware.o.o | ||
| -- | -- | ||
| V8.1 | Test in real machine | QA Reviewer | |
| X8.1 | A new release is published | ||
| D8.1 | Bug report | ||
openSUSE Dev. and Int. Process High Level Description
Purpose
This section provides an overview of the complete openSUSE Factory Development Process and describes the development process shared by the Milestones (up to the release of Beta1). The goals of the process are:
- To develop openSUSE and move it from the roadmap to the Beta 1 stage
- Coordinate the efforts to balance the new features (development process) with the quality of the distribution (review process and QA), guided by the features and deadlines established in the roadmap.
Entry Criteria
- Product Manager and Release Manager decide that a new release cycle can begin
Tasks
- Roadmap and Feature Planning. The Release Manager creates the initial roadmap [1] [2] [3] by putting in the number of milestones, betas and release candidates that need to be released for the distribution. The schedule is adjusted taking into consideration vacations and other constraints described in the Roadmap Process. In parallel, developers from the community will decide a set of technical goals for the distribution based on the projected release and freeze dates [4] [5], using the mailing list and documenting these features in openFATE [6][7] or in a dedicated wiki page per project (see T1.3 for a further description about how the features are decided). The feature freezes are scheduled as part of this task.
- Package Development. The development process starts in OBS [8] in a home project. The Package Developer can create or fix applications here without affecting anything else. Once he/she considers it good enough a submit request to a devel project can be created. In case of new packages the developer has to find the proper Devel Project to send the submit request to.
- Devel Project Integration. The Devel Project is maintained by the Project Maintainer and it is his/her task is to check the technical quality of the different submit requests sent to the project. There are many devel projects grouped by topics, each with a number of Project Maintainers assigned. Some projects have an internal review process not visible in the process work flow diagram. Other parts of the review process will be made explicit in other levels in this documentation, for example, the security review process. If the developer needs to fix the package, he / she branches the package into his / her own home project and creates a submit request to the original devel project. Those request can be approved by the Project Maintainer and by the Package Maintainer (only for his / her own packages)
- Factory Integration. The Factory Maintainer and the Release Managers accept the submit requests that come from the different devel projects to Factory [9]. All submissions to Factory have to comply to the policies checked in the verification task Review. As we will see later, this verification guarantees that (The net result is that the Factory Maintainer and the Release Manager can approve the request with only a brief examination):
- There is a minimal technical quality level for the package (it compiles, the spec file syntax is correct, etc.)
- The license is compatible with our policies
- The package has had a basic security review.
- Release Process. If the QA process has passed, the release of the milestone or beta can be executed by the Release Manager. The tasks involved here are similar to the work that needs to be done for the release of the distribution: calculate the ISO MD5/SHA1 hashes, set up the repositories, prepare and seed to the mirrors, deploy the products and kick marketing to communicate the release.
Verification
- Review Process. The review process is used to filter and improve the quality of the submit requests to Factory, and avoid certain stability problems that can be created in T2 and T3. All packages on their way to Factory go through 4 (sometimes 5) reviews:
- Quality Assurance Process (openQA). After Factory, when the Release Manager or the automatic system (OBS) decides that an ISO image can be created for the different products, the QA process takes place. The ISO image is used to run through a predefined set of test in order to detect failures in the integration or bugs in the packages itself. If issues are found, a report is created pointing to the failures in the ISO image.
Exit Criteria
- Release Manager and Product Manager declare Beta 1 status
- Beta 1 products are released and announced in the mailing lists and other communication channels