Specifications for this cycle :

Daily upstream builds of Xfce

Perform daily upstream package builds of Xfce trunk for testing & debugging

• Launchpad entry: daily-upstream-builds-xfce

• Release target: Karmic

• Contributors: CodySomerville

• Field of the spec: Team Infrastructure

Summary

The goal is to take the trunk of Xfce (only core components for now) every night and attempt to build two sets of debian packages: relatively unmodified (as close as vanilla upstream as possible) and patched as normal (modified with our usual set of patches).

Rationale

This will provide us with a number of benefits which include, but are not limited to, the following:

1. Early detection of problems, issues, and concerns
2. Easier to help test the latest and greatest Xfce
3. Easier to test if a bug has been fixed already or not
4. Easier to determine if a bug is our fault or really a bug upstream

Use cases

• Jenny, an Xfce developer, asks Zelda to test some changes she made to xfce4-mixer's slider controls the other day. Zelda easily installs the xfce4-mixer from the PPA and finds that she can no longer move the sliders to change the volume after setting them to max. Zelda removes the xfce4-mixer from the PPA and re-installs the latest version from the Xubuntu after sharing a laugh about the bug with Jenny.
• Zorro wants to help contribute to Xubuntu/Xfce via testing/QA so he enables the PPA in Software Sources. Since Zorro gets the latest from trunk every day, he is able to keep up with development and helps make Xubuntu/Xfce better by helping spot bugs and problems early.
• Wayne, a Xubuntu developer, is trying to debug a tricky issue that seems to be only affecting Xubuntu users. Wayne uses the packages from the two PPAs (vanilla vs. Xubuntu) and determines the issue is with an old Xubuntu patch (or really is in Xfce).
• Zippy has the nightly build PPAs enabled but a change in the source code upstream makes the packages fail to build. No one has gotten around to fixing the issue for awhile and when Zippy reports the issue to Xfce developers the Xfce developers get frustrated.

The specification

Design

We'll use launchpad's ability to import remote GIT branches into launchpad hosted bzr branches. They will be marked as trunk of their respective launchpad project.

A team will be created to own the two bzr branches per Xfce component (vanilla vs. xubuntu) and two PPAs that will host the packages of the respective bzr branches (again, vanilla vs. xubuntu). Initially, we'll start with the Xubuntu packages.

Since we'll be building GIT, we'll need to patch the rules file to call autogen.sh and make distcheck before configuration begins and the control file to depend on xfce4-dev-tools plus other misc packages (like libtool). These changes will be maintained in a branch called "grumpy" and will continuously merge in applicable updates from the branch containing the packaging for the current development release of Xubuntu.

The bzr-builder tool will be used to automate the preparation and upload of each Xfce component to the PPAs for the launchpad buildds to build. The tool will probably initially be hosted/ran on my machine but we'll naturally want to get more permanent hosting somewhere more reliable.

The bzr-builder tool uses recipes to construct a working directory to build the source package from. These recipes will be maintained in a bzr branch located at lp:~xubuntu-xfce-daily-builds/+junk/recipes For more details, see https://wiki.ubuntu.com/DailyBuilds/BzrBuilder

Notes on the implementation

All imports recreated to point at git. Some may still be waiting in queue for initial import.

Session

Libraries

Applications

Extra maintenance work after the spec

• The tool will need to be maintained to ensure it keeps running.
• We'll need to maintain the debian packaging used to build the packages (mitigated by the magic of bzr)
• We'll need to update all the imports once Xfce switches to git
• We'll need to poke launchpad developers to fix any import failures if they occur