Planning and executing the Linaro cycle


Published on

How Linaro plan's, debates, works on, and ultimately delivers a game changing release every 6 months.

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Planning and executing the Linaro cycle

    1. 1. Planning and Executing the Linaro Cycle Jamie Bennett, Release Manager
    2. 2. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    3. 3. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    4. 4. Requirements Who makes the decisions on what will be worked on in Linaro?
    5. 5. Requirements Requirements are defined by the Technical Steering Committee (TSC) which is made up of the Linaro Chief Technical Officer (CTO), the Vice President (VP) of engineering and a representative from each of the Linaro Core and Club members. See and for more information
    6. 6. Requirements When are the decisions made?
    7. 7. 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 Specification document by the CTO, with input from the Technical Leads (TL) of each engineering team.
    8. 8. Requirements Around one month before the Linaro Developer Summit (LDS) the TSC gathers to discuss the Technical Specification. The items that are approved are collated together in the Technical Requirements document. This document defines what Linaro will be working on for the upcoming cycle.
    9. 9. 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 specification detailing the requirements implementation, goals, and expected outcomes.
    10. 10. Requirements At LDS each Blueprint is discussed with interested parties. The feasibility and importance is defined 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.
    11. 11. 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.
    12. 12. Requirements Just before Feature Definition Freeze the TSC will meet to ensure that the Technical Requirements have been captured as expected during the definition phase.
    13. 13. 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.
    14. 14. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    15. 15. Linaro Developer Summit (LDS) What is the Linaro Developer Summit?
    16. 16. Linaro Developer Summit (LDS) Linaro members at the Ubuntu Developer Summit in Belgium before Linaro was announced.
    17. 17. Linaro Developer Summit (LDS) • Co-hosted with the Ubuntu Developer Summit • Officially 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 for more information
    18. 18. Linaro Developer Summit (LDS) Who is the Linaro@UDS Summit for?
    19. 19. Linaro Developer Summit (LDS) • Developers interested in contributing to Linaro. • Tech Leaders interested in influencing 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.
    20. 20. Linaro Developer Summit (LDS) What is discussed at the Linaro@UDS?
    21. 21. Linaro Developer Summit (LDS) Small selection of sessions at the last developer summit.
    22. 22. 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 for the latest schedule.
    23. 23. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    24. 24. Blueprints What are Blueprints?
    25. 25. 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 for more information
    26. 26. Blueprints
    27. 27. Blueprints Anatomy • Summary • Priority, status, implementation • Approver, drafter, assignee • Related branches • Whiteboard • Subscribers
    28. 28. 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.
    29. 29. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    30. 30. 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 Definition Freeze, Feature Freeze, and Final Freeze. See for more information
    31. 31. 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 for more information
    32. 32. 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 reflected in the image stability. New features and the majority of changes happen between LDS and Beta. There are exceptions. See for more information
    33. 33. The Release Cycle Beta is a stable release and expected to be functional but with bugs. From this point forwards only bug fixes 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 fixes can be made at this point. See for more information
    34. 34. 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 for more information
    35. 35. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    36. 36. 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 for more information
    37. 37. 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 for more information
    38. 38. Schedule • Requirements Gathering • The Linaro Developer Summit • Blueprints • The Release Cycle • Out of Cycle Contributions • Tracking
    39. 39. Tracking With all the engineering effort going on, how do you track progress?
    40. 40. Tracking • Meetings • Blueprints • Work Items • Burn Down Charts • Wiki Status Pages • Upstream contributions
    41. 41. Tracking Meetings • IRC • Mumble • Conference Calls • Face-to-Face
    42. 42. Tracking Work Items
    43. 43. 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 for more information
    44. 44. Tracking Burn Down Charts
    45. 45. 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
    46. 46. Tracking Wiki Status Pages
    47. 47. 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 for more information
    48. 48. Tracking Upstream Contributions • Upstream contribution trackers • Automated tools coming to better report on contributions • Initial implementation for GCC only can be found at See for more information
    49. 49. Questions?