Diff for "BuildBranchToArchiveUI"

Not logged in - Log In / Register

Differences between revisions 24 and 25
Revision 24 as of 2010-01-29 14:00:04
Size: 8824
Comment:
Revision 25 as of 2010-01-29 14:32:43
Size: 9041
Comment:
Deletions are marked like this. Additions are marked like this.
Line 49: Line 49:
[[http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|Build now overlay|width=400}}]] [[http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|Build now overlay|width=600}}]] (Update to display the recipe owner).
Line 68: Line 68:
[[http://people.canonical.com/~michaeln/bfb/build_now_nonjs_combined.png|{{http://people.canonical.com/~michaeln/bfb/build_now_nonjs_combined.png|Build now overlay|width=600}}]]

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',

Build now overlay (Update to display the recipe owner).

  1. 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:

Build now overlay

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:

Build now overlay

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:

Build now overlay

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

  • 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?
    • We'll need to indicate on the branch page itself all the recipes for this branch - both where the branch is the base, or just mentioned in recipe for a merge etc. Not sure yet of the best way to do that."

  • Do we currently detect when *none* of the branches associated with a recipe add a debian directory?
  • 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?
  • 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]."?
  • 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?
  • 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?

Answered

  • 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.

Notes

BuildBranchToArchiveUI (last edited 2010-03-24 08:24:30 by michael.nelson)