• 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

Refer to BuildBranchToArchive for the non-UI aspects.

The UI issue: unnecessary complexity

Although it is possible for Launchpad users to build a source package from a branch and publish it in their PPA using the bzr-builder plugin, we can radically reduce the complexity of this process and remove the need to transfer data in and out of Launchpad unnecessarily, as nearly all the data is already there on Launchpad (everything except the recipe specifying which branches/revisions to use for the source package).

Goals of the UI

[draft] Users with upload rights to any PPA can, when viewing a branch page:

• build the branch-tip within 3 clicks of the branch page (or a specific revision).
• setup a daily build for the branch by customising the recipe (ie. just a checkbox)
• see the recent builds of that branch (and perhaps a build history for the branch?)
• See all the recipes for the branch (name, owner and distroseries?)

When viewing a source package recipe build within their PPA, users can:

• easily identify the current status of the build (and log etc.)
• view (and edit) the recipe (ie. disabling daily builds)
• ...

Users can view a list of all their recipes (?).

Users can see source package recipe builds when viewing a specific builder's history.

Target user audiences

(draft)

• Current users of bzr-builder for daily builds...
• Opportunistic programmers who...
• QA-leads for large projects...
• Power users of existing projects who want to run trunk (jml) (wouldn't/shouldn't the project set up a daily build, or be encouraged to do so by such power users?)

Use-cases

Please feel free to expand, correct or add further use-cases. Grab the Balsamiq mockup files with:

bzr branch lp:~michael.nelson/+junk/buildfrombranch-mockups

(and propose any merges).

Manual build of the latest branch revision

Guilherme has his own branch of the Toggle project and would like to build and publish the resulting package in his PPA, using the available packaging branch from the distroseries.

While viewing his branch page, Guilherme:

1. clicks on the "Build now" button,
2. An overlay appears displaying the a template recipe to be used as there are not yet any recipes associated with this branch. If there were already recipes available for this branch, Guilherme would have the option of simply selecting one (which would update and display that recipe) or clicking on 'Create new recipe' which would make the relevant fields editable as shown). After checking the packaging branch and selecting the appropriate PPA and clicking 'Start build',

(Update to display the recipe owner).

3. The branch page is updated with a "Recent builds" portlet listing the new build and its status, linking to (somewhere appropriate within) the PPA.

At this point, Launchpad will have created both a new recipe for Guilherme and the first build of that recipe.

Manual build of the latest branch revision (Non-JS version)

Without JavaScript, the "Build now" link would go to a "/+build" page for the branch:

allowing Guilherme to select a recipe and indicate the ppa. If there weren't any recipes, or he wanted to create a new one, he can click on 'create a new recipe' which takes him to:

Once Guilherme successfully creates a new recipe he is redirected back to the +build page above.

Actually, an alternative here (given that it is all for the non-JS version) would be to combine the two pages into one like this:

Manual build of a specific branch revision

Yong-sik works on the ereader project and has a number of PPAs including 'ereader_daily' and 'ereader_beta'. He would like to build a specific revision of ereader and publish the result in his personal PPA. If all goes well after installing the resulting package, he'll copy this source and resulting binaries into the ereader_beta PPA.

Yong-Sik opens the Launchpad page for his devel branch and then:

1. clicks on the "Build now" button,
2. ...

Daily builds

Yong-sik works on the ereader project and has a number of PPAs including 'ereader_daily' and 'ereader_beta'. He now wants to automate his daily builds.

Yong-sik opens the Launchpad page for his devel branch and then

1. clicks on the "Build now" button,
2. ...

Initial design proposal

TODO: (the following is just a preservation of data, not an indication of design).

• List required/affected traversals
  • (code?) ~owner/distro/distroseries/sourcepackagename/recipename
  • (code?) ~owner/+recipes
  • (code) path_to_branch/+recipes (displays both recipes identifying the branch as the base, as well as recipes which merge the branch etc. )
  • code: path_to_branch/+buildbranch (non-js version)
  • /builders/buildername/+history (link existing bug for this)

Design and interaction questions

Still requiring thought

• None of the current mockups consider the distroseries of recipes, but the user should only be able to select recipes for the distroseries to which they want to publish - this information is available in the changelog of the packaging branch, but it won't be in the DB until the source package is uploaded. How can we do this consistently? In a way it seems as though we want the recipe to define the distroseries, but it won't, the changelog will.
• Similarly, the sourcepackagename is defined in the changelog of the packaging branch - information which we won't have until the source package is uploaded, but we need to create the recipe first - how can we do this consistently?
• Our current schema doesn't support daily builds (as the archive is only mentioned on the SPRBuild, not on SPRecipe). How will we update the schema to support specifying daily builds?

Answered (to some degree)

• What if the user who wants to build a branch doesn't have a PPA (or upload privileges to one)?

  • Eventually we'd like to see PPA creation seamlessly interwoven with the build process, but initially this option will only be available to users who have upload rights to a PPA

• How will malformed recipes be handled?

  • When submitting the recipe text, normal LPForm validation will indicate errors. Eventually it'd be great to check the recipe text client-side.

• What if I have need a recipe that combines many branches for a build, not just one main one?

  • Free-form editing of the bulk of the recipe text will be possible, but so far we don't think it would be a good idea to be able to edit the base_branch.

• Why do users even need to know about recipes when creating an initial build - can't we potentially determine a related packaging branch?

  • There is no standard way to construct packaging branches as yet. Some may be pure packaging info, which will require nesting into a 'debian' directory, others will contain the debian directory and require just a simple merge. Similarly, there may be other custom merges required as well. So it seems that even initially we'll need to expose the recipe in all its glory.

• How will users who have no experience with bzr-builder be able to create a recipe?

  • We hope we'll be able to do most of the work to display a sane template. But we will need help available for the recipe commands and the revision spec options.

• How will I be notified of the progress of my build?

  • Similar to the current soyuz build infrastructure, you will be able to view the build as soon as it's created and it will display the estimated time until dispatch or the current state etc. We haven't discussed emailing on success/failure, but I guess we'll need to do that too?"

• What if theris already a recipe for the given branch, how will the user know to use that instead?

  • The ui will encourage users to choose from one of the available recipes for the branch before creating their own.

• Do we currently detect when *none* of the branches associated with a recipe add a debian directory?

  • No, and we can't do this as it's not in the DB (and we can't poke bzr from LP code).

• When displaying the resulting source package in the PPA, would we also want something like "There is a newer revision available for this source package branch [build now]."?

  • Yes.

• Eventually, in a years time, we may have *lots* of recipes on certain branches (say a project's trunk) for different distroseries. How will we display a sensible selection of recipes?

  • Perhaps restrict the recipes by the current release, devel and LTS distroseries?

• I'm assuming that part of our validation when creating a build should be that the evaluated deb-version will be greater than all current versions in the target PPA?

  • Yes.

• Should users be free to specify the complete deb-version? (deb-version 1.0+{revno}-{revno:packaging}), Or how can we simplify this? We could do auto {revno} and {revno:packaging}, but this could lead to issues when the same users creates a build using a *different* packaging branch that has a lesser version?

  • Currently we can't see any other possibility without some very intelligent algorithm that checks the destination ppa publishings etc., even then we'd still need the option of manual specification.

• The destination target needs a progress indicator. For PPAs, the detail packages page should show the source package in the construction (builddeb) phase, which conceptually is before anything it shows right now. How will we do this?

  • We could include it in the latest updates portlet, but this may not be sufficient.

Notes