BlueprintHowto

Differences between revisions 6 and 12 (spanning 6 versions)
⇤ ← Revision 6 as of 2010-04-21 15:51:18 →
Size: 4645
Editor: c-76-105-148-120
Comment:
← Revision 12 as of 2011-10-18 13:24:55 → ⇥
Size: 4556
Editor: leannogasawara
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<Include(Kernel/MenuBar)>>
Line 9: Line 11:
|| Name || For the Ubuntu Kernel Team, we typically try to name all of our blueprints with the same prefix. The naming convention is usually, kernel-<release>-<short description>. For example, for the Lucid release cycle, we used [[https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-lucid-bug-handling|kernel-lucid-bug-handling]] for the blueprint that focused on how we were going to improve or bug management.|| || Name || 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, [[https://launchpad.net/ubuntu/+spec/hardware-p-kernel-config-review|hardware-p-kernel-config-review]] ||
Line 18: Line 20:
|| Series Goal || Set to the release target. ||
Line 20: Line 23:
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 [[https://wiki.ubuntu.com/SpecTemplate|template]]. For the Ubuntu Kernel Team, we usually create all of our specs under http://wiki.ubuntu.com/KernelTeam/Specs/ . At a minimum, create a placeholder for the spec based on the [[https://wiki.ubuntu.com/SpecTemplate|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. 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 [[https://wiki.ubuntu.com/SpecTemplate|template]]. For the Ubuntu Kernel Team, we usually create all of our specs under http://wiki.ubuntu.com/KernelTeam/Specs/ , for example https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview . At a minimum, create a placeholder for the spec based on the [[https://wiki.ubuntu.com/SpecTemplate|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.
Line 23: Line 26:
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 gobby) which is a collaborative text editor. These notes often help draft the final revision of a 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.
Line 25: Line 28:
The UDS-M schedule for the entire week will eventually be posted at http://summit.ubuntu.com/uds-m/ The UDS-P schedule for the entire week will eventually be posted at http://summit.ubuntu.com/uds-p/
Line 31: Line 34:
Work items ubuntu-10.04-beta-1:
[leannogasawara] apport -- prevent reporting against linux-meta, moving to linux:DONE
[leannogasawara] apport -- interactive kernel hooks:INPROGRESS		 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
Line 35: Line 39:
Work Items for ubuntu-10.04-beta-2:
[jeremyfoshee] documentation -- review X's debug focused wiki pages [amber]:DONE
[jeremyfoshee] arsenal -- use the apport release to tag bug series:DONE
[leannogasawara] apport/arsenal -- consolidate crash reports as we do for coredumps:POSTPONED		 Work Items for ubuntu-12.04-beta-2:
[canonical-foundations] disable apport kerneloops:TODO
Line 40: Line 42:
Work Items for ubuntu-10.04:
[apw] kerneloops -- ensure ubuntu oopses are detected correctly:TODO		 Work Items for ubuntu-12.04:
[leannogasawara] Final kernel content and configuration report to ubuntu-devel:TODO

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: https://blueprints.launchpad.net/ubuntu

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:

Name

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

Title

Short descriptive title of the blueprint

Specification URL

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

Summary

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.

Assignee

Person responsible for completing the spec/blueprint.

Drafter

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

Approver

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 http://wiki.ubuntu.com/KernelTeam/Specs/ , for example https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelConfigReview . 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.

UDS

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 http://summit.ubuntu.com/uds-p/

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)