Home Home > 2013 > 09 > 18 > Documenting the openSUSE Development and Release Process
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Documenting the openSUSE Development and Release Process

September 18th, 2013 by

This week, the openSUSE Team Blog is written by Agustin Benito who talks about how we’ve been documenting our work around openSUSE.

Development a GNU/Linux based distribution like openSUSE can be divided in two major phases:

  • openSUSE Development process: creation and integration of the different packages. Milestones (alphas) and Beta.
  • openSUSE Release process: stabilization, QA and task related with the availability of the different images. Update process. From Beta to the Release.

There are also three major continuous actions throughout the process:

  • Management of the process.
  • Communication and marketing related tasks.
  • Development of new features

The development of new features usually happens upstream or within SUSE (in collaboration with community members) before it is added to the distribution. This phase takes place before or in parallel with the Development process (of packages and integration).

Focus: the openSUSE Team

The decision taken by SUSE during 12.2 to concentrate the SUSE employees working on openSUSE in a single department by creating the openSUSE Team had as consequence that new people has joined us to work in openSUSE. One of the early decisions within the openSUSE Team at SUSE was to put more focus on the distribution. The Release Team was created as a subset of the openSUSE Team, formed by Coolo and Tomas (Ismail Dönmez and Michal Hrušecký were also part of it in the past) to take care of the Development process. It was also decided that the whole Team would have as major goal to drive the Release process.
documentation icon

Documenting the process

Starting in July 2012, the openSUSE Team at SUSE has put effort in documenting the Development + Release process. Throughout the years, the process has evolved and some of those changes were not documented or the documentation was not up to date. We have taken the opportunity to analyze the the Dev+Release process, so we could learn from it and being able to design and execute changes to improve it.

The release process

As Team, we focused first on the Release process. We made an initial effort during the last few weeks of the 12.2 Release process, and we improved it during the first milestones of the 12.3 Release. For this 13.1 Release, only minor updates have been required.

Increasing the efficiency of the management side of things and structuring our work as a formal project has been another aspect of this. We set up a management tool that now is used together with the openSUSE sysadmin team. Ludwig Nussel is the controller of our efforts as team in the Release, planned through progress.opensuse.org. The combination of this planning and the improved release documentation has helped us to increase our efficiency despite new people joining our team.

The development process

During the past few weeks we have concentrated our efforts in analyzing and documenting the Development process. Our goal has been to analyze it, providing a high level view and just the minimum amount of details required to understand it by people with some knowledge of these kind of software integration processes.

We have recently published a draft of the Development process on the openSUSE Factory mailing list and are open for feedback.

Writing process

How was this document done?

      1.- The first action was to analyze existing documentation about the Development process. We took as sources several articles from openSUSE wiki and some previous analysis done by the former Boosters Team in this area.
      2.- We organized two sessions in which different people described the different steps of the process. These sessions were taped.
      3.- We transcribed the sessions and created a first document containing all the information about the process.
      4.- We processed that “story” in order to get the high level view of the process.
      5.- Using the ETVX methodology, we elaborated a first draft of the document.
      6.- We analyzed the result within the openSUSE Team and, after introducing some changes, we opened the discussion about it to other SUSE employees involved in the Development process.
      7.- Finally, in order to make the document easier to read (it is a complex process, so the documentation needs time to digest), we introduced improvements in the format and published in the openSUSE wiki, together with the .pdf version.

This process has allowed us to analyze and discuss the process as a team, learning not just about the hows but the whys. It has also worked as a test for documenting future changes in how openSUSE is developed. We also hope that the effort can be worth it to contributors that want to get a high level view of how openSUSE works, since some of the tasks are done in house. This document has to be seen also as an exercise of transparency.


At openSUSE Team, we are strong believers of the principle “no data -> no analysis -> no improvements“. We think we are better prepare now to propose to the community improvements in factory to make it more usable for a wider range of contributors.
statistics with Geeko inside

Statistics Time

And like every week, we present you the top-ten of contributors to Factory!

Spot Hacker
1 Raymond Wooninck
2 Dominique Leuenberger
3 Dirk Mueller
4 Dr. Werner Fink, Bjørn Lie
5 Sascha Peilicke
6 luce johann, Michal Vyskocil
7 Michael Schröder
8 Stephan Kulow
9 Ismail Donmez
10 Cristian Rodríguez

Both comments and pings are currently closed.

One Response to “Documenting the openSUSE Development and Release Process”

  1. Monk Mallow

    Hi, I have a question about progress.opensuse.org: I could not find a possibility to take over a task as an openSUSE contributor. It seems that you have to be in a special circle of people to become active there, in fact, all people in there seem to be employees of SUSE. That feels like a contradiction to what was emphasised earlier in the openSUSE community, which was that tasks should be explicitely open to non SUSE employed community members. Also it seems to be very micro managing, not sure if that is needed and applicable for an open source project.

    Or have you given up on trying to become an open source project or being community driven? This tool seems to be a step in the wrong direction for me.