launchpad development|
⇤ ← Revision 1 as of 2010-08-05 16:40:52
Size: 2731
Comment:
|
Size: 2858
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 45: | Line 45: |
| Line 57: | Line 58: |
| ''What are the workflows for this feature?'' ''Provide mockups for each workflow.'' '''''You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.''''' |
* Create a recipe based on a branch * Investigate a broken build triggered by a failure mail * ...? |
| Line 64: | Line 64: |
| ''How will we know when we are done?''<<BR>> Constraints, Must and Must Not are satisfied. ''How will we measure how well we have done?''<<BR>> We will look at the graphs of the popularity of source package recipe builds and daily builds. |
* [[https://lpstats.canonical.com/graphs/CodeRecipeBuildsDailyStatusCounts/|Daily totals of the results of the builds in the last 24 hours]] * [[https://lpstats.canonical.com/graphs/CodeRecipeTotalCounts/|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.]] * [[https://lpstats.canonical.com/graphs/CodeRecipeOwnerCounts/|How many different people use recipes]] |
| Line 72: | Line 72: |
| ''Put everything else here. Better out than in.'' | I think getting a timely build done is a must. |
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
[[https://lpstats.canonical.com/graphs/CodeRecipeBaseTypeCounts/|The number of projects and packages that are used
as recipe base branches.]]
Thoughts?
I think getting a timely build done is a must.
