openSUSE Development and Integration Process

From Roadmap to Beta1

Version 1.1.0 - 25/09/2013 Author: openSUSE Team at SUSE

About this document

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.

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):
  1. There is a minimal technical quality level for the package (it compiles, the spec file syntax is correct, etc.)
  2. The license is compatible with our policies
  3. 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:
  1. Factory-Auto: an script that checks basic rules [10]
  2. Legal-Auto: a script checking if the license of the package is in the permitted license database [10]
  3. Repo-Checker: a more in depth (and slow) automatic check [10]
  4. Review Team: human check of the request.
• 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

Deliverables

• XML Document with the roadmap [4]
• openSUSE Team meeting minutes
• Milestones and Beta 1 ISO images and repositories [14]
• Announcement of the release

Category:

• Factory