Diff for "BuildBranchToArchiveUI/UseCaseManualBuild"

Not logged in - Log In / Register

Differences between revisions 1 and 29 (spanning 28 versions)
Revision 1 as of 2010-02-09 12:05:58
Size: 2902
Comment:
Revision 29 as of 2010-02-15 12:55:28
Size: 9623
Comment: Removed out-of-date non-js mockups.
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
= A typical manual build of the a branch = = Typical manual branch build use-cases =
Line 4: Line 4:
Guilherme has his own branch of the Toggle project and would like to build and publish the resulting package in his PPA, using his own version of the official packaging branch. '''Note''': the following mockups do not try to fit the current implementation of bzr builder recipes or the corresponding current LP models.
Line 6: Line 6:
== Initiating the build for the first time == == Build my bugfix branch - existing recipe ==

Guilherme has his own branch of the Toggle project that fixes a bug and would like to build and publish the resulting package in his PPA.

While viewing his branch, Guilherme:
 1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED)
 1. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published. By default, the recipe selector is displaying "toggle_std_pkging by Toggle Dev Team" and the displayed recipe description states "This is the default recipe for building Toggle. It merges the official packaging branch only." The description also informs him that the recipe targets Lucid and 9.10. Guilherme realises that it's exactly what he wants and simply clicks "Build now".
[[http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2.png|Build now overlay}}]]
 1.#3 The overlay disappears and the branch page is updated with a "Recent builds" portlet listing the new build and its status (MOCKUP REQUIRED), linking to (somewhere appropriate within) the PPA.

== Build my bugfix branch - new recipe ==
Guilherme has his own branch of the Toggle project that fixes a bug and would like to build and publish the resulting package in his PPA.
Line 9: Line 20:
[[http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay.png|Build now overlay|width=1000}}]]
 1. clicks on the "Build now" button (or "Create a build" or "Build this"),
 1. An overlay appears displaying a template recipe to be used as there are not yet any recipes associated with this branch (image on the right). If there were already recipes available for this branch, Guilherme would have the option of simply selecting one (image on the left) or clicking on 'Create new recipe' which would expand the Recipe details and make the relevant fields editable as shown (image on the right). After checking the packaging branch and selecting the appropriate PPA and clicking 'Start build',
 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.
 1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED),
 1. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published, and then reads the recipe description and realises straight away that it's not what he wants. He clicks on the recipe selector and selects the only other option. He reads the description of this second recipe, realises it's also not something he can re-user, and so clicks on the "Create a new recipe" link.
[[http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2.png|Build now overlay}}]]
 1.#3 The overlay transitions (fade in/out) to a "Create a build recipe for Toggle" overlay (shown below). Guilherme enters a useful name and description for his new recipe, selects his packaging branch and clicks save.
[[http://people.canonical.com/~michaeln/bfb/create_recipe_v2-collapsed.png|{{http://people.canonical.com/~michaeln/bfb/create_recipe_v2-collapsed.png|Create recipe}}]]
 1.#4 The overlay transitions back to the previous "Build this branch to a PPA" dialog, with his new recipe already selected. Guilherme clicks 'Build now'.
 1. The overlay disappears and the branch page is updated with a "Recent builds" portlet listing the new build and its status, linking to (somewhere appropriate within) the PPA.
Line 14: Line 28:
At this point, Launchpad will have created both a new recipe for Guilherme and the first build of that recipe. == Initiating a build for a specific branch version or target distro series ==
Line 16: Line 30:
== Determining the state of the current build ==

A few minutes later, Guilherme decides to check on how his build of his branch is progressing...

== Re-using the recipe for a subsequent build ==

A week later, Guilherme needs to create and publish a specific version of his branch into a separate PPA...
A week later, Guilherme needs to create and publish a specific version of his branch into a separate PPA. While viewing his branch, Guilherme:
 1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED)
 1. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published. By default, the recipe selector is displaying "toggle_std_pkging by Toggle Dev Team" and the displayed recipe description states "This is the default recipe for building Toggle. It merges the official packaging branch only." The description also informs him that the recipe targets Lucid and 9.10. Guilherme realises that it's exactly what he wants - but he'd like to select a specific version of his branch, so he clicks on the "Build options" expander:
[[http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2-expanded.png|{{http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2-expanded.png|Build now overlay}}]]
 1.#3 Guilherme selects the specific revision that he needs, and clicks "Build now"
 1. The overlay disappears and the branch page is updated with a "Recent builds" portlet listing the new build and its status, linking to (somewhere appropriate within) the PPA.
Line 25: Line 38:
NOTE: the mockups for this section need to be updated.
Line 28: Line 42:
[[http://people.canonical.com/~michaeln/bfb/build_now_nonjs.png|{{http://people.canonical.com/~michaeln/bfb/build_now_nonjs.png|Build now overlay|width=600}}]]
[Add back in after updating]
Line 32: Line 47:
[[http://people.canonical.com/~michaeln/bfb/create_recipe_nonjs.png|{{http://people.canonical.com/~michaeln/bfb/create_recipe_nonjs.png|Build now overlay|width=400}}]] [Add back in after updating]
Line 36: Line 51:
Actually, an alternative here (given that it is all for the '''non-JS version''') would be to [[http://people.canonical.com/~michaeln/bfb/build_now_nonjs_combined.png|combine the two pages into one]] (nope, that ui is getting too complicated, and it's just for the non-js version, better to keep it as two simpler pages).

= See also =

 * [[BuildBranchToArchiveUI/UseCaseDailyBuild]]
 * [[BuildBranchToArchiveUI/UseCaseComplexRecipe]]

= Unresolved questions =
 * A simplified case when no previous recipes exist. For the case where there are no previous recipes associated with a project branch, would it be possible to simply request a packaging branch (with the option to create a full recipe as well)?
   * ''This would create a recipe with a name based on the packaging branch name for all current distroseries. The user would be informed when they click 'Build now' etc. of the recipe creation, so they could always updated it/rename it etc. afterwards if the like.''
 * Should all recipes be available for selection in the dropdown, or just 'official' ones (ones owned by members of the project team?), or both but segregated in the dropdown (ie. official first, then community).
  * ''We should include membership in Ubuntu devs for some sort of 'official' recipe status.''
 * With the revision specification, perhaps it should be a radio button with Tip selected by default, but the second radio would enable a text box. It'd be nice to also have a dropdown with recent revisions (with commit msgs!?) without crowding the interface.

Mockups that are missing, maybe:
 * A page for a build
   * Failed
   * Successful
   * How does it use the manifest?
 * A page for a daily build (is this the same as the page for a recipe)
   * Most recent builds
   * When building next?
   * Stop building this for now / resume
   * What has changed on the branches since the most recent build?

Unaddressed use-cases:
 * As a gnome-do enthusiast, I want to install the daily build for "gnome-do" so I can use the latest crack.
   * ''I think the question here is how do I *find* the gnome-do daily PPA right?''
 * Should we have a page that represents a recipe? If so what would it be for & what would it look like?
   * ''Definitely - I mean, we want people to be able to edit the recipe. I assume it would look very similar to the recipe creation overlay above, but include more auxiliary info like builds that have been done with the recipe etc.''

= Resolved questions =
 * James says, from a technical pov, we don't need the source package name field at all, and in fact, it can't be used for anything useful. James will actually remove the --package option from bzr dailydeb, as it's not even required when there's no changelog entry, as it must be present in the control file.
   * ''Removing from the mockups. Although we still then need a discussion around the recipe traversal URL, as the last time this was discussed they were to be traversed via the SPName, which LP won't currently have access to even though it is data in one of the branches referenced by the recipe and (currently) we will have that data once the source package is uploaded.''
 * What is a general rule that can/should be used for deciding what's in a recipe and what's external?
   * ''Anything which is to do with the inputs to the recipe (ie. what goes together to make the source package) should be inside the recipe. But what you do with the result (ie. which distroseries etc.) should be external.''
   * ''The version template is not clear, as it's useful as a default on the recipe, but useful as an override for users too.''
 * Is it worthwhile having a structured advanced recipe options? (ie. instead of a text area for the advanced options, allowing users to select a branch, command (merge/nest), and reference, version etc.)
   * ''That could end up being more complicated than advanced users using a text area, considering nesting of instructions etc.''
 * Regarding the build options: does it make sense to have a branch revision *and* Build daily as an option at the same time?
   * ''It is conceivably possible that someone might want a daily build of a fixed base-branch revision because the merged feature branch or packaging branch etc. is what is being tested, but I've no idea whether this is realistic. If not (or even if so) we can simply warn the user when they click Build daily if they have selected a version.''
   * ''Spoke with James - agreed it's possible (although not normal), so warning is a good solution.''

Typical manual branch build use-cases

Note: the following mockups do not try to fit the current implementation of bzr builder recipes or the corresponding current LP models.

Build my bugfix branch - existing recipe

Guilherme has his own branch of the Toggle project that fixes a bug and would like to build and publish the resulting package in his PPA.

While viewing his branch, Guilherme:

  1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED)
  2. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published. By default, the recipe selector is displaying "toggle_std_pkging by Toggle Dev Team" and the displayed recipe description states "This is the default recipe for building Toggle. It merges the official packaging branch only." The description also informs him that the recipe targets Lucid and 9.10. Guilherme realises that it's exactly what he wants and simply clicks "Build now".

Build now overlay

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

Build my bugfix branch - new recipe

Guilherme has his own branch of the Toggle project that fixes a bug and would like to build and publish the resulting package in his PPA.

While viewing his branch page, Guilherme:

  1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED),
  2. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published, and then reads the recipe description and realises straight away that it's not what he wants. He clicks on the recipe selector and selects the only other option. He reads the description of this second recipe, realises it's also not something he can re-user, and so clicks on the "Create a new recipe" link.

Build now overlay

  1. The overlay transitions (fade in/out) to a "Create a build recipe for Toggle" overlay (shown below). Guilherme enters a useful name and description for his new recipe, selects his packaging branch and clicks save.

Create recipe

  1. The overlay transitions back to the previous "Build this branch to a PPA" dialog, with his new recipe already selected. Guilherme clicks 'Build now'.
  2. The overlay disappears and the branch page is updated with a "Recent builds" portlet listing the new build and its status, linking to (somewhere appropriate within) the PPA.

Initiating a build for a specific branch version or target distro series

A week later, Guilherme needs to create and publish a specific version of his branch into a separate PPA. While viewing his branch, Guilherme:

  1. Clicks on the "Build this branch" link, (MOCKUP REQUIRED)
  2. A "Build this branch to a PPA" overlay appears displaying a selection for his target PPA and someone elses recipe that has been created to build toggle branches (shown below). Guilherme selects his target PPA where he wants the package to be published. By default, the recipe selector is displaying "toggle_std_pkging by Toggle Dev Team" and the displayed recipe description states "This is the default recipe for building Toggle. It merges the official packaging branch only." The description also informs him that the recipe targets Lucid and 9.10. Guilherme realises that it's exactly what he wants - but he'd like to select a specific version of his branch, so he clicks on the "Build options" expander:

Build now overlay

  1. Guilherme selects the specific revision that he needs, and clicks "Build now"
  2. The overlay disappears and the branch page is updated with a "Recent builds" portlet listing the new build and its status, linking to (somewhere appropriate within) the PPA.

Notes for graceful degradation - Non-JS version

NOTE: the mockups for this section need to be updated.

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

[Add back in after updating]

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:

[Add back in after updating]

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

See also

Unresolved questions

  • A simplified case when no previous recipes exist. For the case where there are no previous recipes associated with a project branch, would it be possible to simply request a packaging branch (with the option to create a full recipe as well)?
    • This would create a recipe with a name based on the packaging branch name for all current distroseries. The user would be informed when they click 'Build now' etc. of the recipe creation, so they could always updated it/rename it etc. afterwards if the like.

  • Should all recipes be available for selection in the dropdown, or just 'official' ones (ones owned by members of the project team?), or both but segregated in the dropdown (ie. official first, then community).
    • We should include membership in Ubuntu devs for some sort of 'official' recipe status.

  • With the revision specification, perhaps it should be a radio button with Tip selected by default, but the second radio would enable a text box. It'd be nice to also have a dropdown with recent revisions (with commit msgs!?) without crowding the interface.

Mockups that are missing, maybe:

  • A page for a build
    • Failed
    • Successful
    • How does it use the manifest?
  • A page for a daily build (is this the same as the page for a recipe)
    • Most recent builds
    • When building next?
    • Stop building this for now / resume
    • What has changed on the branches since the most recent build?

Unaddressed use-cases:

  • As a gnome-do enthusiast, I want to install the daily build for "gnome-do" so I can use the latest crack.
    • I think the question here is how do I *find* the gnome-do daily PPA right?

  • Should we have a page that represents a recipe? If so what would it be for & what would it look like?

    • Definitely - I mean, we want people to be able to edit the recipe. I assume it would look very similar to the recipe creation overlay above, but include more auxiliary info like builds that have been done with the recipe etc.

Resolved questions

  • James says, from a technical pov, we don't need the source package name field at all, and in fact, it can't be used for anything useful. James will actually remove the --package option from bzr dailydeb, as it's not even required when there's no changelog entry, as it must be present in the control file.
    • Removing from the mockups. Although we still then need a discussion around the recipe traversal URL, as the last time this was discussed they were to be traversed via the SPName, which LP won't currently have access to even though it is data in one of the branches referenced by the recipe and (currently) we will have that data once the source package is uploaded.

  • What is a general rule that can/should be used for deciding what's in a recipe and what's external?
    • Anything which is to do with the inputs to the recipe (ie. what goes together to make the source package) should be inside the recipe. But what you do with the result (ie. which distroseries etc.) should be external.

    • The version template is not clear, as it's useful as a default on the recipe, but useful as an override for users too.

  • Is it worthwhile having a structured advanced recipe options? (ie. instead of a text area for the advanced options, allowing users to select a branch, command (merge/nest), and reference, version etc.)
    • That could end up being more complicated than advanced users using a text area, considering nesting of instructions etc.

  • Regarding the build options: does it make sense to have a branch revision *and* Build daily as an option at the same time?
    • It is conceivably possible that someone might want a daily build of a fixed base-branch revision because the merged feature branch or packaging branch etc. is what is being tested, but I've no idea whether this is realistic. If not (or even if so) we can simply warn the user when they click Build daily if they have selected a version.

    • Spoke with James - agreed it's possible (although not normal), so warning is a good solution.

BuildBranchToArchiveUI/UseCaseManualBuild (last edited 2010-03-02 16:04:46 by michael.nelson)