Diff for "BuildBranchToArchiveUI"

Not logged in - Log In / Register

Differences between revisions 10 and 11
Revision 10 as of 2010-01-28 09:47:26
Size: 5215
Editor: jml
Comment:
Revision 11 as of 2010-01-28 10:49:19
Size: 6757
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

Refer to BranchBuildToArchive for the non-UI aspects.
Line 13: Line 15:
 * 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?)
Line 14: Line 18:
When viewing a source package recipe build with their PPA, users can: When viewing a source package recipe build within their PPA, users can:
Line 19: Line 23:
(other ui points, such as available recipes for a branch etc.) Users can view a list of all their recipes (?).
Line 26: Line 30:
 * Power users of existing projects who want to run trunk (jml)  * 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?)
Line 72: Line 76:
== Unresolved questions ==
== 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."

=== 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."
Line 75: Line 95:

 * May need to handle malformed recipes
 * Need to handle case where no PPA yet exists
 * Not just build ''from branch'', recipes can be multi-branch
 * Probably need to link out to actual documentation on recipes :(
 * Potentially long-running process, how are users notified of failure
 * If there's already a recipe for a branch, maybe we should guide someone to look at that?
   * if it's the base branch of a recipe
   * if it's just mentioned in the recipe

Refer to BranchBuildToArchive 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

[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 (?).

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.

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 default packaging branch (or a default recipe?) that will be used (with the option to choose from other available options, or customise a new recipe on a separate page), as well as a PPA selector. After selecting the appropriate PPA and clicking 'OK',
  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.

Questions:

  1. Currently Recipes are *base-branch*-specific (SPRD.base_branch) rather than packaging-branch-specific? This means that a new recipe is required for each branch of a project, even though they may all use the same packaging branch. If it was the other way around, it would be possible to re-use the recipe for different branches... rather than having to duplicate most of the info into a new recipe? (move SPRData.base_branch to SPRecipe?)
    • Right. A new Recipe is required, but the packaging branch can be re-used. Perhaps we should detect already-used packaging branches and suggest them to a user?

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
    • ~owner/distro/distroseries/sourcepackagename/recipename
  • The source package branch page needs a PPA/distro picker and a build button to start a build. Obviously the pickers will be sensitive to upload permissions. [Check - the wording here implies setting a default ppa for subsequent builds, rather than selecting the PPA when clicking on 'Build now'? -- michael.nelson 2010-01-25 15:37:34]

  • 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.
  • It would be nice if, when displaying the result in the PPA, something like "There is a newer revision available for this source package branch [build now].

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

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

Notes

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