Home Wiki > openSUSE:Development Process
Sign up | Login

openSUSE:Development Process

tagline: From openSUSE

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.


Opensuse-development-process.png


Roadmap and Feature Planning
ETVX
Code
Name
Role
Entry
E1.1 Previous release version of the distribution was released
Task
T1.1 Create the roadmap description Release Manager
T1.2 Feature freeze calendar Release Manager
T1.3 Determine the new features Project MaintainerPackage Maintainer
Verification
V1.1 Review the roadmap Product ManagerRelease Manager
V1.2 Roadmap maintenance Release Manager
Exit
X1.1 The roadmap and the freeze calendar are published in the mailing list
Deliverable
D1.1 XML Document with the roadmap
D1.2 Features documented in openFATE and in the wiki


Package Development
ETVX
Code
Name
Role
Entry
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
Task
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
Verification
V2.1 Is in Factory Package Developer
V2.2 Automatic checks complete successfully Package Developer
Exit
X2.1 Developer creates a submit request in OBS
X2.2 Developer drops the change, aborting the development process
Deliverable
D2.1 Submit Request


Devel Project Integration
ETVX
Code
Name
Role
Entry
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
Task
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
Verification
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
Exit
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
Deliverable
D3.1 Submit request to Factory


Review Process
ETVX
Code
Name
Role
Entry
E4.1 A submit request is created by a Project Maintainer for Factory
Task
-- --
Verification
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
Exit
X4.1 All the reviews are positive
X4.2 There is a negative review
Deliverable
D4.1 Status of the submit request


Factory Integration
ETVX
Code
Name
Role
Entry
E5.1 Submit request reviewed
E5.2 The Factory Maintainer decides to fix an issue inside Factory
Task
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
Verification
V5.1 Is Factory open for submissions? Factory MaintainerRelease Manager
V5.2 Brief review Factory Maintainer
Exit
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
Deliverable
D5.1 Package integrated into Factory
D5.2 A building Factory repository


Quality Assurance Process
ETVX
Code
Name
Role
Entry
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
Task
T6.1 Create a new test QA Reviewer
T6.2 Test maintenance QA Reviewer
T6.3 Create bug reports QA Reviewer
Verification
V6.1 Test review QA Reviewer
Exit
X6.1 Important / critical test are green. The ISO is candidate for release
X6.2 Important / critical bug is detected. The ISO is rejected
Deliverable
D6.1 Test report
D6.2 Bug report


Release Process
ETVX
Code
Name
Role
Entry
E7.1 It is 2 days before the chosen release date
Task
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
Verification
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
Exit
X7.1 Release is available and announced
Deliverable
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
ETVX
Code
Name
Role
Entry
E8.1 A new release (Milestone or Beta) is published in sofware.o.o
Task
-- --
Verification
V8.1 Test in real machine QA Reviewer
Exit
X8.1 A new release is published
Deliverable
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):
    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