Summary

Server daily builds provide a user or a developer a way to test upstream versions before they are included in Ubuntu. As a user it allows users to test new features before they reach Ubuntu. As a developer, it provides a way of testing fixes before they can be integrated into Ubuntu.

Rationale

Server daily builds provide both the user and a developer a way to test new upstream versions before they are included in Ubuntu. This is especially important by providing a way to:

User stories

Design

Selection of packages

The packages that were selected are the following:

Launchpad group/PPA

Similar to the xorg-edgers group a launchpad group will be created in order to use the PPA system in order to distribute the daily server packages. An option to keep each source in their own PPA is also in consideration.

Bzr branches

Bzr branches will be used to keep track of the changes to the the debian/ directory.

bzr builder

Bzr builder uses recipes in order to build dailies. This will be the basis of Daily Server packages, the recipes will be kept in a bzr branch as well

Upstream source

Daily server builds will use existing launchpad tools to import upstream code into bzr trees in order to keep track of them.

Unresolved issues

The unresolved issues are the following:

BoF agenda and discussion

Upstream projects such as PHP and Apache prefer that users who are reporting bugs with their software to use the latest unmodified software in order to test fixes. We should provide a PPA for users to install unmodified upstream software so we can provide quality bug reports for our upstreams.

Agenda:

* Discuss why we need it
* packages that are targeted (and why)
* How we might do it
  * Generally using bzr-builder infrastructure
  * Soon, LP will do it
  * When imports don't work?

* Which packages to include and why?
  * apache [chuck]
  * samba [chuck]
  * openldap [mathiaz]
  * puppet [mathiaz]
  * qemu-kvm [dustin] (maybe kvm-autotest)
  * libvirt [dustin]
  * eucalyptus [dustin]
  * mysql [mathiaz]
  * couchdb [chuck]
  * postgresql [chuck]
  * postfix [chuck]
  * cups [???]


* Which packages should we have daily builds for:
  * ones that move quickly
  * ones that are easily tested
    * automated tests ftw
  * (ideally, all of them)

* How can we promote it?
  * Blog about it
  * Create teams with badges ala xorg-edgers (sp?)
  * Linking in Launchpad
    * From the package, see the daily build
    * From a bug, see PPAs that link to the daily builds that fix it
    * From project, link to the daily build

== Use cases ==
 * daily builds of qemu-kvm (git).
 * daily build bisection (to figure out which version broke/fixed):
   need to archive the daily builds (deb-marshall does this)
 * users wants to test the latest tip of postgresql (git), couchdb (apache svn repo), erlang (soon on github).
 * machines using the daily builds to detect regressions etc.

== Issues ==

 * LP git import is breaking
   e.g. https://code.edge.launchpad.net/~vcs-imports/qemu/git

 * How to get a community excited about the daily builds? 
   Hard to for server packages (db), easier for desktop packages.
   
 * If we're only building daily packages for lucid, then we have a high barrier
   to entry for casual testers.
   
 * Takes a while to set up right now, need to think of how it actually helps
 
 * If upstream build breaks often (tsk tsk) then be careful about subscribing
   lists.
   
 * Maintaining difference between minimally patched debian/ directory for daily 
   builds and debian/ directory for Ubuntu release is time consuming.
   * Difference increases the closer to release we get.

== Contacts ==

Everyone below knows how to do this.

 * dustin
 * james_w
 * mathiaz
 * ChuckShort [chuck]
 
Launchpad and Bazaar are working on daily builds as #1 focus. Talk to jml 
or vila (or any othe bzr team member).

== Actions ==

ACTION: jml to investigate reducing the roundtrip time from "bug in code imports"
to "working code imports". (Probably moving code imports to edge) 
(an alternative is having another code import service and publish the fixed 
imports from there)

ACTION: jml to investigate keeping archives of daily builds for improved
debugging bisection.

ACTION: (someday) bzr team to look into which packages move the fastest

ACTION: james_w to find out whether the git hash is preserved (and if not, make
it so)

ACTION: people noted above to start packaging this.

ACTION: chuck to set up & publish PPA location for this


CategorySpec

DailyServerBuildsSpec (last edited 2009-12-02 13:09:10 by CPE0006258ec6c1-CM000a73655d0e)