• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Source Package Recipe Builds

Build source packages from bzr-builder recipes, optionally on a daily basis.

As an upstream maintainer
I want to be able to build packages of my code using pre-existing packaging
So that users can try out the latest tip without installing from source.

This is not the elimination of sourcepackages as a step towards generating binary packages as proposed in No More Source Packages. Instead, it attempts to make that step trivial for many authors who otherwise wouldn't publish binaries.

Rationale

Why are we doing this now?
Our focus on "bridging the gap".

What value does this give our users? Which users?
It makes it easier for our upstreams to provide daily builds of tip for Ubuntu.

It should increase the availability of up-to-date binaries of upstream for Ubuntu users, to improve testing and provide early access to new features.

Stakeholders

• Upstreams
• Ubuntu community leaders
• Soyuz
• Losas
• Ubuntu OSAs

Some of these stakeholders only have an interest in ensuring the build farm is reliable even with this new feature.

Constraints and Requirements

• Must safely execute untrusted code when building source packages
• Only the build farm provides for safe execution of untrusted code
• Must use bzr-builder to generate debianized trees

Must

• Provide daily builds, but may skip builds if the source is unchanged.
• Provide a web UI for creating recipes and requesting builds
• Provide API for creating recipes and requesting builds
• Allow users to use James Westby's imports to provide the debian directory

Nice to have

• Auto-scheduled Source Package Recipe Builds don't interfere with manually-scheduled ones
• Builds are performed in a timely manner
• Users can cancel builds
• Builds of recipes involving private branches are supported.

Must not

• Overload the build farm
• Disable the build farm

Workflows

• Create a recipe based on a branch
• Investigate a broken build triggered by a failure mail
• ...?

Success

• Daily totals of the results of the builds in the last 24 hours

• Count the total number of recipes grouping on the branch namespace type and whether there is a daily build.

• [[https://lpstats.canonical.com/graphs/CodeRecipeBaseTypeCounts/|The number of projects and packages that are used

as recipe base branches.]]

• How many different people use recipes

Thoughts?

I think getting a timely build done is a must.