Diff for "BuildBranchToArchiveUI"

Not logged in - Log In / Register

Differences between revisions 19 and 20
Revision 19 as of 2010-01-28 15:02:58
Size: 7812
Comment:
Revision 20 as of 2010-01-28 15:11:13
Size: 8332
Comment:
Deletions are marked like this. Additions are marked like this.
Line 105: Line 105:
   ''When submitting the recipe text, normal LPForm validation will indicate errors. Eventually it'd be great to check the recipe text client-side."    ''When submitting the recipe text, normal LPForm validation will indicate errors. Eventually it'd be great to check the recipe text client-side.''
Line 108: Line 108:
 * 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.''

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

Manual build of the latest branch revision (no previous recipes)

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.

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

Without JavaScript, the "Build now" link would go to "/+buildbranch" (Note: +new-recipe doesn't work when there are already recipes to choose from.)

Manual build of the latest branch revision (previous recipes defined)

A few pushes later, Guilherme is keen to build a new version from his branch, so he:

  1. clicks on the "Build now" button,
  2. This time, the overlay displays the name and (editable) contents of his previous recipe. Guilherme just checks that the right PPA is selected and hits 'OK' [1].
  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.

[1] If Guilherme had chosen to modify the recipe in any way then it would have created a new recipe (in this case, forcing him to change the recipe name). If other people had also created recipes for this same branch (a team branch, for example), then the recipe name would be a combo box instead which, when changed, populates the recipe fields with the appropriate contents.

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?

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)