he future of continuous integration in gnome

Colin Walterswalters@verbum.org

Daniel M. Germandmg@uvic.ca

Germán Poo-Caamañogpoo@gnome.org

The Future ofContinuous Integration

in GNOME

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”

Release Management in FOSS

Developmentreleases

Majorend–user

stablereleases

Minorreleases

[Michlmayr et al, 2007]

Release Management in FOSS

Developmentreleases

Majorend–user

stablereleases

Minorreleases

People can only test releases when all the components work together, which usually

is a distribution

Interrelated Components

GTK+ Clutter

GIO

GStreamer EDS

GLib libnotify gnomekeyring

Geographically Distributed

[https://live.gnome.org/GnomeWorldWide]

Distributed Through Intermediaries

Current Workflow

Late Detection of Regressions

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

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?

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

Deploy an entire operating system in one single checkout and to allow

rollback to a previous version

Expected Workflow

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

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

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.