Download - he Future of Continuous Integration in GNOME
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.
