Diff for "BuildBranchToArchiveUI"

Not logged in - Log In / Register

Differences between revisions 35 and 36
Revision 35 as of 2010-02-01 15:50:06
Size: 12483
Comment:
Revision 36 as of 2010-02-02 09:49:04
Size: 12819
Comment: Added bug refs.
Deletions are marked like this. Additions are marked like this.
Line 93: Line 93:
Note: we don't currently have db schema support for this - see question below. Note: we don't currently have db schema support for this - see [[https://bugs.edge.launchpad.net/launchpad-code/+bug/515923|bug 515923]].
Line 102: Line 102:
 * 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?  * 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 ([[https://bugs.edge.launchpad.net/launchpad-code/+bug/515923|bug 515923]])?
Line 144: Line 144:
   ''The mockups have been updated to include distroseries and package name. There is still a related issue due to the current schema (spnames required before upload - add bug)''    ''The mockups have been updated to include distroseries and package name. There is still a related issues, one related to the current schema (spnames required before upload - [[https://bugs.edge.launchpad.net/soyuz/+bug/515581|bug 515581]] which is perhaps ok), and spname/suite not being passed to dailydeb - [[https://bugs.edge.launchpad.net/soyuz/+bug/515918|bug 515918]]''

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

We can create a simple UI, that in the best case, presents a selection of target PPA and source package recipe, but the details of the recipe still need to be available to the user for inspection and of course when creating a new recipe.

Please update this page with any ideas of your own, especially the questions section.

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 his own version of the official packaging branch.

While viewing his branch page, Guilherme: Build now overlay

  1. clicks on the "Build now" button,
  2. 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',
  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 "/+buildbranch" 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 (nope, that ui is getting too complicated, and it's just for the non-js version, better to keep it as two simpler pages).

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.

We could add a dropdown next to the base-branch on the above overlay mockup with 'Tip' selected by default.

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.

This could be achieved by adding scheduling options to the previous mockups: Build now overlay with scheduling

Note: we don't currently have db schema support for this - see bug 515923.

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

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

Design and interaction questions

Still requiring thought

  • 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 (bug 515923)?

    • wgrant suggested some type of 'schedule' that would generalise to also allow automatic builds in other conditions.

  • What is the complete set of URLs that will be updated as part of this work?
    • (code) path_to_branch (eg. ~owner/myproject/feature_x). Required: new "Build now" link, and latest builds portlet.
    • code: path_to_branch/+buildbranch (non-js version). New page to create a recipe build
    • A traversal for creating new recipes - I personally think this will be best close to the base-branch of the recipe (ie. path_to_branch/+new-build-recipe - we create a recipe for the base-branch, not a recipe for the distroseries/sourcepackagename and perhaps specify an incorrect base-branch), but there might have been more thought on this in the past?
    • (code) path_to_branch/+recipes (displays both recipes identifying the branch as the base, as well as potentially recipes which merge the branch etc. )
    • (code?) ~owner/distro/distroseries/sourcepackagename/recipename The canonical traversal for displaying a recipe.
    • (code?) ~owner/+recipes: all recipes owned/created by a person
    • /builders/buildername/+history: needs to display different types of builds, rather than just binary builds (bug 491330)
    • ~username/+archive/mytargetppa/+builds : needs to display different types of builds, rather than just binary 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.

  • 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.
    • The mockups have been updated to include distroseries and package name.

  • 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?
    • The mockups have been updated to include distroseries and package name. There is still a related issues, one related to the current schema (spnames required before upload - bug 515581 which is perhaps ok), and spname/suite not being passed to dailydeb - bug 515918

Notes

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