KarmicDailyBuilds

  • Launchpad Entry: foundations-karmic-daily-builds

  • Created: 12 Jun 2009

  • Contributors: James Westby and many others

  • Packages affected: bzr-builder (to be included)

Summary

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.

Rationale

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

  • Rob finds a bug in gwibber. He is asked to verify that the bug still exists in trunk, and so he installs the package from the PPA to test. Once he has verified whether the bug still exists he can choose to return to the distribution version, stay on the fresh version, or keep receiving daily builds.
  • Michael is a big fan of the gnome-do package and he wants to contribute where he can. In order to do this more effectively he wants to run the new code that the developers are talking about so that he can help to test it. He subscribes to the daily build of gnome-do, so that whenever a developer adds a new feature he can be testing it the next day.
  • Anne is a developer on KMail. She wishes to work on integrating some in-development features of the KDE libraries in to the app. In order to do this though she needs to track the development of the libraries she will be using very closely, so that the newest features and fixes for them are available to her and she is testing the latest code. To do this she subscribes to a PPA that contains the daily builds for all the libraries that she is interested in, and the libraries that they depend on. Every day she gets the latest code with an apt-get upgrade, rather than pulling from the VCS and building the libraries. This leaves her more time for working on the integration.
  • Toby works on a package in Ubuntu. He sets up a daily build of the package so that he can get early warning of build failures when it is built on Ubuntu, dependency changes, and other things. This means that when a release is made he has less work to do to get the package ready for the distribution.

Assumptions

Work

Tool

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.

Community

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:

  • Have Launchpad builders able to assemble a source package as well as just build one.
  • Use the above to assemble the source package of the daily build using the instructions of the tool
  • Allow people to register and edit instructions for a daily build.
  • Schedule these instructions, and report failures to assemble or build to the appropriate people.
  • Do whatever it takes so that apport knows what to do with bugs from the built packages.

Unresolved issues

BoF agenda and discussion


CategorySpec

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