In Free and Open Source Software (FOSS) projects
based on Linux systems, the users usually install the software
from distributions. The distributions act as intermediaries be-
tween software developers and users. Distributors collect the
source code of the different projects and package them, ready
to be installed by the users. Packages seems to work well for
managing and distributing stable major and minor releases. It
presents, however, various release management challenges for
developers of projects with multiples dependencies not always
available in the stable version of their systems. In projects like
GNOME, composed of dozens of individual components, devel-
opers must build newer versions of the libraries and applications
that their applications depend upon before working in their own
projects. This process can be cumbersome for developers who are
not programmers, such as user interaction designers or technical
writers. In this paper we describe some of the problems that the
current distribution model presents to do continuous integration,
testing and deployment for developers in GNOME, and present
ongoing work intended to address these problems that uses a git-
like approach to the building and deployment of applications.
2. Motivation
● Colin's experience in Fedora and GNOME:
“Easier for Fedora QA to install LXDE than to
help to debug and fix GNOME”
“User Experience Designers want to see what
they are designing”
3. Release Management in FOSS
Development
releases
Major
end–user
stable
releases
Minor
releases
[Michlmayr et al, 2007]
4. Release Management in FOSS
Development
releases
Major
end–user
stable
releases
Minor
releases
People can only test releases when all the
components work together, which usually
is a distribution
12. Problems
● Challenge for collaboration between different kind of
contributors (Interaction between designers and programmers)
● Barrier of entry for potential new developers as building
the system becomes more complex
● Detection of regressions can be delayed making the
quality assurance process slower
● Difficult to test development versions as a whole without
the risk of breaking the system
13. Research Goal
● How can the release management process be
improved to allow any potential contributor to try
the latest versions available without breaking their
system, and allow them to easily switching between
a testing and a development environment?
14. OSTree: Continuous Integration System
● Version Control System designed for binaries
● Build system for applications
● Deploy a Linux–based operating system in a similar
way as developers use version control system
15. Deploy an entire operating system
in one single checkout and to allow
rollback to a previous version
18. Benefits
● Developer do not have to build the dependencies
for their projects
● Test a development version by running them on a
daily basis
● Does not disrupt developer's existing system
● Possible to bisect across operating system builds
● User can participate bisecting
● Provides a reference system
19. Status
● It is being used by some early adopter developers
● The build system is working for one specific architecture
● Images to test
– http://ostree.gnome.org/work/images/z/current/
● More details in paper and https://live.gnome.org/OSTree
● Source code:
– https://git.gnome.org/browse/ostree
– https://git.gnome.org/browse/gnome-ostree
20. Conclusions
● It is difficult to deploy test versions when there are
too many components interrelated. As a
consequence, this reduces the participation of users
and potential new contributors
● OSTree combines features from a version control
and package systems to offer multiple versions of a
program and multiple parallel installations.
● It makes possible to try a project like GNOME
minutes or hours after a change has been
committed in the source code repository.
