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.
Link this from build-from-branch blueprint
Rationale
Why are we doing this now?
It is not a blocker, but it is part of the BuildBranchToArchive implementation.
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
Who really cares about this feature? When did you last talk to them?
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 SourcePackageRecipe and BinaryPackage builds.
When Builder history pages such as Samarium's history display a contiguous list of batched SourcePackageRecipe, TranslationTemplate and BinaryPackage 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.
Thoughts?
Put everything else here. Better out than in.