Diff for "LEP/GeneralBuildHistories"

Not logged in - Log In / Register
Differences between revisions 5 and 6
⇤ ← Revision 5 as of 2010-03-31 15:45:53 →
Size: 4103
Editor: michael.nelson
Comment:
← Revision 6 as of 2010-04-09 11:36:58 → ⇥
Size: 4116
Editor: jml
Comment:
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
''Who really cares about this feature? When did you last talk to them?'' Same as build from branch – XXX: need to have a general LEP tying that together
Line 58: Line 58:
Line 68: Line 69:

General Build Histories

Present a list of different builds (binary builds, source recipe builds) in a single batched history

As a developer building branches to PPAs
I want to view and search all builds targeting a given PPA
so that I can see the history of my branch builds and find build failures of all types.

As an admin of the Launchpad build system
I want to browse the history of a builder to see binary, source and translation builds
so that I can identify and investigate a builders throughput of jobs.

  • This feature will not change the UI for the builder history or PPA builds views, rather it will enable those views to include and batch all builds rather than just the current binary builds.

The Build generalisation blueprint will be used to track the breakdown of this feature into small tasks.

The planning and links to email discussions for this feature are available on bug 536700

Rationale

Why are we doing this now?

What value does this give our users? Which users?

  • Developers using build-branch-to-archive mainly, giving them one point to view all builds related to their PPA.

Stakeholders

Same as build from branch – XXX: need to have a general LEP tying that together

Constraints

What MUST the new behaviour provide?

What MUST it not do?

Workflows

What are the workflows for this feature?

Provide mockups for each workflow.

  • This feature will not change the UI for the builder history or PPA builds views, rather it will enable those views to include and batch all builds rather than just the current binary builds.

You do not have to get the mockups and workflows right at this point. In fact, it is better to have several alternatives, delaying deciding on the final set of workflows until the last responsible moment.

Success

How will we know when we are done?

When PPA pages such as fta's main PPA display a contiguous list of batched source package recipe builds and binary package builds.

When Builder history pages such as Samarium's history display a contiguous list of batched source package recipe builds, translation template builds, and binary package builds.

How will we measure how well we have done?

By the simplicity of the change to the browser/template code. If the architecture of the model/db changes is good, it should be simple to update the batched views themselves.

Release Note

This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log. It is mandatory.

When viewing a build-farm builder history (or all the builds for your PPA), you will not only see binary builds, but also other types of builds such as source package recipe builds, or translation template builds.

Thoughts?

Put everything else here. Better out than in.

Implementation plan

As this will be a significant amount of work, we want to plan it to enable the work to be done in parallel. Here are the current thoughts. Each line in the following spreadsheet could be a separate branch/task/bug.

Implementation dependencies

  • Note: By only removing the old soyuz build data in a schema patch after all the separate areas have been updated, we can migrate each area separately, ensuring that tests continue to pass.

  • Note2: Although it would be nice to remove BuildQueue/BuildPackageJob tables and related job records, it won't be necessary to present the generalised build histories.

LEP/GeneralBuildHistories (last edited 2010-04-09 11:36:58 by jml)