he future of continuous integration in gnome
DESCRIPTION
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.TRANSCRIPT
Colin [email protected]
Daniel M. [email protected]
Germán Poo-Caamañ[email protected]
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.
