Planning and executing the Linaro cycle

Planning and Executing the Linaro Cycle Jamie Bennett, Release Manager Linaro.org

Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking

Requirements Who makes the decisions on what will be worked on in Linaro?

Requirements Requirements are deﬁned by the Technical Steering Committee (TSC) which is made up of the Linaro Chief Technical Ofﬁcer (CTO), the Vice President (VP) of engineering and a representative from each of the Linaro Core and Club members. See http://www.linaro.org/how-linaro-works/ and https://wiki.linaro.org/TSC for more information

Requirements When are the decisions made?

Requirements Around two months before the Linaro at Ubuntu Developer Summit (L@UDS) a Call for Requirements (CFR) is made to the TSC members asking what they would like to see in the next release. These requirements are collated together to form the initial Technical Speciﬁcation document by the CTO, with input from the Technical Leads (TL) of each engineering team.

Requirements Around one month before the Linaro Developer Summit (LDS) the TSC gathers to discuss the Technical Speciﬁcation. The items that are approved are collated together in the Technical Requirements document. This document deﬁnes what Linaro will be working on for the upcoming cycle.

Requirements The month between the Technical Requirements being accepted and LDS is used by the engineering teams to produce Blueprints. These Blueprints are accompanied by a speciﬁcation detailing the requirements implementation, goals, and expected outcomes.

Requirements At LDS each Blueprint is discussed with interested parties. The feasibility and importance is deﬁned and implementation details are discussed. The outcome of a LDS session should be a clearer understanding of the requirement and valuable input from a wide audience.

Requirements The two weeks after LDS are spent improving the initial specification, adding input from LDS and defining the individual steps that need to be taken for the requirement to be fulfilled. At this stage a Tech Lead will sign off the Blueprint and implementation can start.

Requirements Just before Feature Deﬁnition Freeze the TSC will meet to ensure that the Technical Requirements have been captured as expected during the deﬁnition phase.

Requirements Before Feature Freeze the TSC will meet again to review the set of features implemented at this stage and relate them back to the original Technical Requirements document. There is a small scope for last minute changes here.

Linaro Developer Summit (LDS) What is the Linaro Developer Summit?

Linaro Developer Summit (LDS) Linaro members at the Ubuntu Developer Summit in Belgium before Linaro was announced.

Linaro Developer Summit (LDS) • Co-hosted with the Ubuntu Developer Summit • Ofﬁcially called Linaro@UDS • 300+ participants from Canonical, Linaro, the community and anyone interested • Linaro discussions around all aspects of the ARM ecosphere • Next Summit October 25th-29th 2010 in Orlando Florida See http://wiki.linaro.org/Events/2010-10-LDS for more information

Linaro Developer Summit (LDS) Who is the Linaro@UDS Summit for?

Linaro Developer Summit (LDS) • Developers interested in contributing to Linaro. • Tech Leaders interested in inﬂuencing and contributing to the direction Linaro takes in the next 6 months. • Community members interested in participating in the Linaro ecosphere. • Partners, OEMʼs, ISVʼs and Downstreams interested in leveraging Linaroʼs effort. • Upstreams interested in ensuring their software is integrated well into Linaro.

Linaro Developer Summit (LDS) What is discussed at the Linaro@UDS?

Linaro Developer Summit (LDS) Small selection of sessions at the last developer summit.

Linaro Developer Summit (LDS) • All Sessions start off as Blueprints in Launchpad including informational only sessions. • Sessions are Scheduled by hand from the pool of Blueprints registered against the current Developer Summit. • Not all sessions can be accommodated. The relative merit of each session will be a factor in the schedule organisers decision to approve or disapprove. • If you are interested in a session, subscribe to the relavant Blueprint in Launchpad. • See http://summit.ubuntu.com for the latest schedule.

Blueprints What are Blueprints?

Blueprints A Blueprint is used to track the development of a project, a feature or any other process towards its goal. Blueprints are used extensively by the Linaro project. See http://www.launchpad.net/+tour/feature-tracking for more information

Blueprints

Blueprints Anatomy • Summary • Priority, status, implementation • Approver, drafter, assignee • Related branches • Whiteboard • Subscribers

Blueprints Anatomy • Summary • One paragraph explanation of what the blueprint is tracking. • Priority, status, implementation • Shows blueprint importance, status and current format. • Approver, drafter, assignee • People involved in completing the blueprint. • Related branches and bugs • Any code or bugs related to the blueprint. • Whiteboard • Free-form text used to track progress. • Subscribers • People who want to be informed of progress.

The Release Cycle The Release Cycle is made up of 6 releases over a 6 month period. 3 Alpha releases, 1 Beta, 1 Release Candidate and 1 Final Release. In between releases, various milestones are created to ensure the release is on track. These include Feature Deﬁnition Freeze, Feature Freeze, and Final Freeze. See http://wiki.linaro.org/Process/Cycle for more information

The Release Cycle Two of the most important milestones when dealing with new features are Feature Definition Freeze and Feature Freeze. By Feature Definition Freeze all new features should be clearly defined and requirements should not change much. By Feature Freeze, all new features will be close to fully implemented. No new features will be added. See http://wiki.linaro.org/Process/Cycle/ReleaseStages for more information

The Release Cycle Alpha releases are primarily targeted at early adopters. There is a great deal of changes that go on in the early release stages and that is reﬂected in the image stability. New features and the majority of changes happen between LDS and Beta. There are exceptions. See http://wiki.linaro.org/Process/Cycle/ReleaseStages for more information

The Release Cycle Beta is a stable release and expected to be functional but with bugs. From this point forwards only bug ﬁxes happen as the release is stabilised. Release Candidate is produced 1 week before release. In a perfect world there would be no changes from this point until release but last minute small ﬁxes can be made at this point. See http://wiki.linaro.org/Process/Cycle/ReleaseStages for more information

The Release Cycle Final Release should be completely stable and fully functional. Minor bugs could be present but any known bugs will be documented in the release notes. See http://wiki.linaro.org/Process/Cycle/ReleaseStages for more information

Out of Cycle Contributions Work is constantly going on both inside and outside of Linaro. The various Working Groups and other Engineering Units, including Landing Teams, produce outputs that do not necessarily line up with the release milestones. See http://wiki.linaro.org/Process/AdvancedDevelopment for more information

Out of Cycle Contributions The output from these groups can be accepted into the release at any point up until the Freeze Period. Work outside of the release schedule is called Advanced Development. See http://wiki.linaro.org/Process/AdvancedDevelopment for more information

Tracking With all the engineering effort going on, how do you track progress?

Tracking • Meetings • Blueprints • Work Items • Burn Down Charts • Wiki Status Pages • Upstream contributions

Tracking Meetings • IRC • Mumble • Conference Calls • Face-to-Face

Tracking Work Items

Tracking Work Items • Assignee in brackets • e.g. [JamieBennett] • Description of item todo • Status of item • TODO, DONE, LATER, POSTPONED • LATER used to track items that miss their deadline • POSTPONED used to track items that do not get done in the cycle See http://wiki.linaro.org/Process/WorkItemsHowto for more information

Tracking Burn Down Charts

Tracking Burn Down Charts • Number of work items over time • Each team has its own burn down chart • Done, Todo, In Progress, Later (slipped) • Other teams items that effect the project also shown • Automatically generated every two hours

Tracking Wiki Status Pages

Tracking Wiki Status Pages • Snapshot of projects current status • Each team has its own status page • Broken down milestone date • Further broken down by blueprint • Further broken down by work item • Easy to see current team status See http://wiki.linaro.org/EngineeringUnits/Status for more information

Tracking Upstream Contributions • Upstream contribution trackers • Automated tools coming to better report on contributions • Initial implementation for GCC only can be found at http://ex.seabright.co.nz/helpers/patchtrack See http://wiki.linaro.org/UpstreamTrees for more information

Questions? jamie.bennett@linaro.org

Planning and executing the Linaro cycle

by JamieBennett

Accessibility

Upload Details

Usage Rights

2 Embeds 873

Statistics

Planning and executing the Linaro cycle Presentation Transcript

http://www.linuxuk.org	872
http://staging.planet.linaro.org	1