At the beginning of every release cycle, we try to create a road map to document the work needed for the next cycle. The work is divided into what we call blueprints and each blueprint is then discussed at UDS. Below is an outline of how to create a blueprint.

Create a Blueprint in Launchpad

A listing of all Ubuntu blueprints can be seen at:

To add a new blueprint just click on the Register a blueprint link. Then fill out each of the input fields keeping the following things in mind:


All blueprints try to follow a naming convention which is suggested by the UDS organizers. For Precise Pangolin 12.04, the naming convention is <track name>-p-<short description>. For example, hardware-p-kernel-config-review


Short descriptive title of the blueprint

Specification URL

This is a link to the spec for the blueprint. See "Drafting the Spec" section below


Short description of what the rationale behind the spec is and what we hope to accomplish

Definition Status

This is initially set to "New". It's set to "Drafting" once the drater/assignee has began drafting the spec. It's set to "Review" when the spec is fully drafted and ready for review. It's set to "Pending Approval" if there are some fixups/changes required of the spec. Finally, it's set to "Approved" when the spec/blueprint is ready to have work started.


Person responsible for completing the spec/blueprint.


Person responsible for taking notes on the discussion at UDS and also for drafting the spec.


Person responsible for approving the spec - usually a manager.

Propose for sprint

Set to the release target.

Series Goal

Set to the release target.

Drafting the Spec

The spec is a wiki page specification outlining the rationale, design, implementation, and testing that will be carried out for a blueprint. Each spec follows the same template. For the Ubuntu Kernel Team, we usually create all of our specs under , for example . At a minimum, create a placeholder for the spec based on the template and set the Specification URL when registering the blueprint. After discussion takes place at UDS, the drafter/assignee will be responsible to go back and fill in each section of the spec.


During UDS, a 1hr session will be scheduled for each blueprint during the week. If you are the assignee or drafter for a blueprint, you are required to attend this session. Be sure to takes notes during the session, especially for any decisions, design ideas, or work items which get discussed. Usually notes are taken in gobby (sudo apt-get install gobby) which is a collaborative text editor. These notes often help draft the final revision of a spec.

The UDS-P schedule for the entire week will eventually be posted at

Approved Specs/Blueprints

Once the spec/blueprint has been approved we can now begin addressing any work items that need to be completed. Each work item should be clearly documented in the whiteboard of the corresponding blueprint. A work item should represent a task that takes approximately 3-5 days work. If it requires longer, the work item should be broken up in multiple work items. Each work item should have a corresponding milestone which the work item is to be completed by. Each work item should also be assigned a specific owner (represented by your launchpad id), else it defaults to the assignee of the blueprint. Additionally, each work item needs to have it's status set to either "TODO", "INPROGRESS", "DONE", or "POSTPONED". An example whiteboard would look like the following:

Work items ubuntu-12.04-beta-1:
[apw] review set of upstream patches:DONE
[leannogasawara] publicise final kernel version after we hit kernel freeze:TODO
[leannogasawara] finalize kernel config changes:INPROGRESS

Work Items for ubuntu-12.04-beta-2:
[canonical-foundations] disable apport kerneloops:TODO

Work Items for ubuntu-12.04:
[leannogasawara] Final kernel content and configuration report to ubuntu-devel:TODO

KernelTeam/BlueprintHowto (last edited 2011-10-18 13:24:55 by leannogasawara)