Diff for "LEP/SourcePackageRecipeBuilds"

Not logged in - Log In / Register
Differences between revisions 1 and 12 (spanning 11 versions)
⇤ ← Revision 1 as of 2010-08-05 16:40:52 →
Size: 2731
Editor: abentley
Comment:
← Revision 12 as of 2010-10-28 16:16:16 → ⇥
Size: 4342
Editor: abentley
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Build source packages from bzr-builder recipes, optionally on a daily basis. Build source packages from [[https://launchpad.net/bzr-builder|bzr-builder]] recipes, optionally on a daily basis.
Line 9: Line 9:
As an Ubuntu enthusiast<<BR>>
I want to make a daily build of my favourite app available in a PPA<<BR>>
So that I & others can always be using the bleeding-edge.<<BR>>
Line 13: Line 17:
''Why are we doing this now?''<<BR>>
Our focus on "bridging the gap".		 We want to make it very, very easy for upstream application authors to get their applications into the hands of Ubuntu users. This allows said application authors to get feedback on their latest work from a large, eager body of open source users. It allows those brave users who want the latest and greatest to get it easily.
Line 16: Line 19:
''What value does this give our users? Which users?''<<BR>>
It makes it easier for our upstreams to provide daily builds of tip for Ubuntu.		 This will, we hope, lead to a higher quality of Linux software in general, and thus a higher quality Ubuntu.
Line 19: Line 21:
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.
Line 28: Line 29:
 * sabdfl
Line 39: Line 41:
 * Provide daily builds, but may skip builds if the source is unchanged.  * Provide daily builds, but may skip builds if the source is unchanged
Line 42: Line 44:
 * Allow users to use James Westby's imports to provide the debian directory  * Allow users to use James Westby's imports (e.g. lp:ubuntu/foo) to provide the debian directory
 * Promptly provide full information on failed builds to the person who requested the build
 * Builds are performed in a timely manner (see [[LEP/BuildFarmScalabilty]] for more details)
 * Provide way to discover recipe-powered daily builds from a project or source package page
 * Allow recipes to be built from bzr 2a-format branches for any supported distorseries (whether or not the distroseries itself supports 2a).
Line 45: Line 51:
Line 46: Line 53:
 * Builds are performed in a timely manner
Line 48: Line 54:
 * Builds of recipes involving private branches are supported.  * Builds of recipes involving private branches are supported
 * Highlight PPAs or packages within PPAs that are generated from recipes
 * Renaming branches does not break recipes
Line 54: Line 62:
 * Require any additional LOSA / buildd-admin intervention
Line 57: Line 66:
''What are the workflows for this feature?''
''Provide mockups for each workflow.''		  * Create a recipe based on a branch
 * Investigate a broken build triggered by a failure mail
 * ...?
Line 60: Line 70:
'''''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.''''' == UI ==
The [[https://dev.launchpad.net/BuildBranchToArchiveUI|original design]] from the process led by Michael Nelson:
[[http://people.canonical.com/~michaeln/bfb/|mockups]]

The [[https://dev.launchpad.net/BuildBranchToArchiveUI/InitialCut|initial cut design]] implemented by Paul Hummer and Aaron Bentley:
[[http://people.canonical.com/~abentley/sprb-mockups/|mockups]]
Line 64: Line 79:
''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]]
 * [[https://lpstats.canonical.com/graphs/BuildersActiveVirtual/|Active builders and jobs queued]] – to see if we broke the build farm.
 * [[https://lpstats.canonical.com/graphs/CodeRecipeDelay|Build delay]]] ­— to see if builds are being dispatched in a timely manner.
Line 71: Line 87:

''Put everything else here. Better out than in.''

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.

As an Ubuntu enthusiast
I want to make a daily build of my favourite app available in a PPA
So that I & others can always be using the bleeding-edge.

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

We want to make it very, very easy for upstream application authors to get their applications into the hands of Ubuntu users. This allows said application authors to get feedback on their latest work from a large, eager body of open source users. It allows those brave users who want the latest and greatest to get it easily.

This will, we hope, lead to a higher quality of Linux software in general, and thus a higher quality Ubuntu.

Stakeholders

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

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 (e.g. lp:ubuntu/foo) to provide the debian directory
  • Promptly provide full information on failed builds to the person who requested the build

  • Builds are performed in a timely manner (see LEP/BuildFarmScalabilty for more details)

  • Provide way to discover recipe-powered daily builds from a project or source package page
  • Allow recipes to be built from bzr 2a-format branches for any supported distorseries (whether or not the distroseries itself supports 2a).

Nice to have

  • Auto-scheduled Source Package Recipe Builds don't interfere with manually-scheduled ones
  • Users can cancel builds
  • Builds of recipes involving private branches are supported
  • Highlight PPAs or packages within PPAs that are generated from recipes
  • Renaming branches does not break recipes

Must not

  • Overload the build farm
  • Disable the build farm
  • Require any additional LOSA / buildd-admin intervention

Workflows

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

UI

The original design from the process led by Michael Nelson: mockups

The initial cut design implemented by Paul Hummer and Aaron Bentley: mockups

Success

Thoughts?

LEP/SourcePackageRecipeBuilds (last edited 2010-10-28 16:16:34 by abentley)