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.

1. ColinWalters
walters@verbum.org
Daniel M. German
dmg@uvic.ca
Germán Poo-Caamaño
gpoo@gnome.org
The Future of
Continuous Integration
in GNOME

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

6. Interrelated Components
GTK+ Clutter
GIO
GStreamer EDS
GLib libnotify gnome
keyring

8. Geographically Distributed
[https://live.gnome.org/GnomeWorldWide]

9. Distributed Through
Intermediaries

10. Current Workflow

11. Late Detection of Regressions

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

17. Expected Workflow

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.