Streamline our process for tracking images included in a release

Registered by Steve Langasek

The existing ReleaseManifest wiki page used for tracking the images including in a release is high-overhead and requires manual synchronization with the actual build infrastructure. Let's obsolete this with something simpler and auto-generated.

Blueprint information

Not started
Steve Langasek
Adam Conrad
Needs approval
Adam Conrad
Pending Approval
Series goal:
Accepted for raring
Milestone target:

Related branches



20121015 - getting the managers to sign off on manifest (images and the publishing location are ok, testing complete and ready to ship) is mostly an exercise in busy work. Need to switch it around so that images aren't built until path for daily and release is known. Also, signoff doesn't happen on wiki page but on
We now have mechanism (images marked ready), so let's retire use of manifest WIKI page.

Whiteboard dump from etherpad follows, to not lose context for WIs:

Daily vs. Release - need to be able to distinguish.

Input file on nusakan needs to be more than default-arches, which expresses what is built as part of daily builds. default-arches was written with the principal aim of simplifying crontab code.
Publish image set which is separated from cdimage code.
Solve by publish set, with publish release. Make it something that CDImage knows how to happen.
Make it in the iso tracker that product manager, release or not tick box, prepopulate from dailies. Adding page on admin side. Copy manifest from prior milestone. Then product manager/admin can choose what added to milestone?
Do we want to manage this per series? Yes, statement of intent per series, then add/remove per milestone.
Respin for release tool, pull out list from iso tracker as candidate for milestone.
(example Edubuntu not publishing ARM on milestone, but wanted to keep it in dailies, how do we make this happen effectively)
(note: dependency on foundations-r-future-release-infrastructure for publish-release rewrite)
? netboot - on iso tracker to record tracking, manifest for netboot stuff is a bit silly - we always ship it.
ISO tracker implementation notes:
- Split builds and milestones (allowing a one to many relationship)
- Add admin UI to link a list of products as default build for a series
- Extend milestone UI to optionally use the list of default products for a milestone
- Builds will always show up on the daily milestone and if any release milestone, will be shown on that milestone too
- Build state will be stored per-milestone
- Any product added to a milestone of the same series as an active testing milestone marked as using default series product will be automatically copied over
Chinese images, same code, but going to second tracker.
Get a team for each product group established for flavors, so they can interact. Work with Nick.
Note: images on publishing pages - split to multiple "images" should be combined. Publishing pages should be reviewed/scrubbed when cjwatson rewrite finishes.
Where we publish to? releases/cdimage - hard coded in publish image set, cross check with iso tracker. Check something before committed to code. publish image set. Point release process is still too manual. Previous archival process - old-releases - needs cleanup.


Work Items

Work items:
[stgraber] Look into referencing images from daily/milestones as single records based on version: DONE
[stgraber] Give the ISO tracker a concept of images that are being released for a series: DONE
[stgraber] Implement admin UI in the tracker and matching API query: DONE
[stgraber] Change code to add builds on the tracker to work with the default milestone products: DONE
[stgraber] Also store release contact per product and per series (same place as what product to publish): DONE
[adconrad] The magical respin-the-world tool should have a --release switch that queries the ISO tracker and only builds the images targetted for release to save resources: TODO
[adconrad] publish-image-set should write the HTML for the netboot page based on the ISO tracker flags, rather than use editing it by hand: TODO
[ogra] Fix stuff that's broken for ARM in make-web-indices (whatever that means): TODO
[kate.stewart] Check with balloons that all products have a launchpad team for people who need QA tracker product management access: TODO

Dependency tree

* Blueprints in grey have been implemented.