Daily Builds can be very useful for users, contributors, and distributions. Relying on them without due care could lead to very serious problems. However, with skilled maintenance and informed users the benefits can outweigh the risk.

There are some projects which currently make use of daily builds in some form, but each generally reinvents the tools that they use to do this. In order to try and avoid everyone having to do this we will try and build a tool that can help with maintaining daily builds.

In addition we will grow a community of those that are making daily builds where knowledge can be shared and best practices grown.

Lastly, we will work with the Launchpad developers to make daily builds easier to set up by building some functionality in to Launchpad. This will leave the maintainers more time to work on making thier set of packages better.

Release Note

None, as this is not something that is for end-user consumption.


Daily builds can be immensely powerful. They massively lessen the barrier to using and testing code that is fresh from the fingers of the developers. They avoid you having to build a project from source every day, making sure to keep up with changes in dependencies. They allow you to be testing code almost as it is written, speeding up the feedback cycle to the developers, and potentially increasing the number of people involved in that feedback cycle.

They also allow you to verify bugs against the latest code, so that bug reports are of more relevance to the developers. If you so choose they can also be set up so that bugs are also tested with fewer distribution patches, further increasing the developers' confidence in the bug reports.

Having the more daily builds available for people to use if they wish allows more projects to get the benefits outlined above. While several projects have daily builds set up, it is still a huge minority of packages in Ubuntu that have any associated daily builds.

We want to build a community that knows how to put together a good daily build, that is useful for its purpose, and minimises the risks as much as possible. This community can then document their best practices and help others set up a daily build. They can also improve the tools, the packaging, and the projects to make daily builds easier and safer.

User stories




There is the bzr-builder tool that is designed to do Daily Builds. It will be improved to meet the needs people have and, if it is suitable, it should become to usual tool for doing daily builds. This means that those wishing to set up a daily build would know to look at this tool first, as it would likely meet their needs. If it doesn't then they can either improve it, or use their own tool. This prevents everyone from having to solve all the problems over again before they can start.

The tool is basically useful now, but it is not well known, and lacks some features, most of which are not yet known. To complete this part we will first talk about the tool so that people know about it, and then work with the users to add the missing features.

Below, Launchpad is discussed, and one of the requirements of this tool should be that it remains possible for it to be run on a central service. This means that all the features it has are acceptable for running other people's daily builds.


We will work to grow a community of people interested in daily builds that can define their own policy on what a "good" daily build looks like. It is not anticipated that this community will be drawn mainly from the currrent Ubuntu development community.

The community will discuss and then document guidelines for setting up, maintaining, and distributing a daily build that others can follow in order to be reasonably assured that their build is maximally useful and minimally risky.

The team will maintain a number of daily builds, either individually, or as part of the team, so that they can get experience of the issues. Sharing this experience and examining the best ways to tackle the problems will allow us to create the guidelines.

The team will look at things like upstream co-operation, emergency procedures, handling dependency build order, allowing users to get back to distribution packages, and version numbering.

Making bugs from the builds most useful

When someone encounters a bug they should know what to do with it, and when it reaches the people that will look at it they should have the information they need already available.

Each daily build should have a bug tracker that bugs should go to (allowing no bug tracker if the software is too young for bugs to be interesting is probably needed), this can either be the upstream tracker, or a separate tracker. This should be easily discoverable to users.

In addition our automated tools should know about it and should send the bugs there. For starters this will mean that Apport will be taught how to find the relevant bug tracker and submit to it.

In addition when there is a crash in a program where the symbols aren't necessarily part of the package the bug should have all the symbol information before any one sees it. This could mean that symbols are not stripped in the daily builds, that we use Ubuntu's retracing, or another solution.

Launchpad integration

Moving much of the automation work in to Launchpad will make it easy for anyone to set up a daily build, and allow them to spend their time on improving the packages.

The community and the Launchpad developers will work together to get the required features in to Launchpad. The preliminary list of these features is:

Unresolved issues

BoF agenda and discussion


FoundationsTeam/Specs/KarmicDailyBuilds (last edited 2009-06-30 19:55:30 by 74)