LCA14: LCA14-103: Roadmap changes
Upcoming SlideShare
Loading in...5
×
 

LCA14: LCA14-103: Roadmap changes

on

  • 278 views

Resource: LCA14

Resource: LCA14
Name: LCA14-103: Roadmap changes
Date: 03-03-2014
Speaker: David Zinman, Kate Stewart
Video: https://www.youtube.com/watch?v=tUGKlO7dT38

Statistics

Views

Total Views
278
Views on SlideShare
278
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

LCA14: LCA14-103: Roadmap changes LCA14: LCA14-103: Roadmap changes Presentation Transcript

  • Mon-3-Mar, 10:05am, David Zinman, Kate Stewart LCA14-103: Roadmap Changes
  • Background: • why the changes? How does this all fit together: • tour of generated roadmaps • TSC, OPSCOM, team information and views What are the changes: • new states • transitions What’s next? Outline
  • • Different teams were using roadmap cards differently. ⇒ Need CONSISTENCY between teams • 1 deliverable per Roadmap card • Deliverables per team should be described in their own roadmap cards • States that make sense to all the teams • Different expectations on “target date” • Set stage for more automation • Too much manual report writing • Data in one place (CARDs), generate different reports from JIRA database based on consistent view of data • Metrics to help guide future improvements • Needed common understanding and agreed to measurement points Background - why the changes?
  • www.linaro.org Idea to Deliverable ENGIN EERIN G DELIVE RABLE REQs DRAFTING CARDs
  • www.linaro.org New Internal Linaro Request Database ■ JIRA based Database “REQ” ■ REQ-# will let requestor know that member request has been logged, and is under consideration by team. ■ Basically free form, using comments to add to knowledge as work up information necessary to create CARD for roadmap. ■ Resolved when item goes on roadmap or its clear that its not going to be in Linaro’s scope.
  • www.linaro.org Requests to CARDs REQ sources: Linaro Members Requests Leads Identifying Gaps Other Linaro Team Needs Key Upstream Requests enough information to create roadmap card? new information? not in scope see: https://wiki.linaro.org/Roadmaps/Process/RoadmapRequests REQs
  • www.linaro.org Request Backlog Processing MEMBER CONFIDENTIAL? STEERING COMMITTEE REQUEST BACKLOG LANDING TEAM REQUEST BACKLOG
  • www.linaro.org Landing Team Backlog Member Contact ARM kanta.vekaria@linaro.org ST kanta.vekaria@linaro.org Huawei/HiSilicon usman.ahmad@linaro.org Fujitsu usman.ahmad@linaro.org Samsung anmar.oueja@linaro.org Broadcom glen.valante@linaro.org Qualcomm TBD Landing Team requirements are captured and managed as CARDs ENGIN EERIN G DELIVE RABLE
  • www.linaro.org Steering Committee Backlog WHICH TEAM? ● LEG-SC: Enterprise ● LNG-SC: Networking ● TSC: Android ● TSC: Kernel ● TSC: Power Management ● TSC: Graphics ● TSC: Toolchain ● TSC: Virtualization ● TSC: Builds and Baselines ● TSC: LAVA ● TSC: Infrastructure ● TSC: QA ● TSC: OCTO topics ● TSC: Security
  • www.linaro.org Team Investigation Before SC Review MEMBER SPONSORED? Linaro+SC CARD DRAFTING PRIVATE CARD DRAFTING MEMBER REVIEW
  • www.linaro.org New Roadmap Card Scope Assessment Linaro+SC CARD DRAFTING >3 months of effort or multiple teams or new area ? Linaro+SC EPIC DRAFTING Linaro+SC CARD DRAFTING SC OPSCOM
  • www.linaro.org CARD State Change CARD DRAFTING CARD APPROVED CARD SCHEDULED CARD DEVELOPMENT or UPSTREAM DEVELOPMENT CARD DELIVERED SC or OPSCOM CLOSING-OUT SC or OPSCOM REVIEW
  • www.linaro.org Development Roadmap Card Symbols Roadmap Symbol JIRA state Meaning Drafting Strategic direction and topic identified to have further planning, before resourcing and prioritization decisions can be made. Preliminary JIRA/blueprints and artifacts may exist in draft form. Forecast date is for a rough target to aim for. Approved Planning has been done for a task, Card has been reviewed by TSC or OPSCOM and approval to go forward has been given. Forecast date may change based on when dependencies are met. Card Fixed Date is further out then one cycle. Scheduled Planning has been done for a task, JIRA Roadmap Card and related blueprints exist and resource estimates and gating dependencies are known. Owner team has been identified and TSC agreed prioritization has been secured. Card has been reviewed by TSC or OPSCOM and approval to go forward has been given. Some preliminary development maybe in progress. Forecast date may change based on when dependencies are met. Development End date is forecast and metrics are being collected. Development is ongoing, developer(s) active. The code, documentation and regression test cases to verify the code are being created. Expectation is that resources are available and dependencies have been met and forecast date reflects high confidence. Closed (Delivered) Work item has been made available to target audience (Members or Public) and all associated artifacts are updated to reflect status. (JIRA cards, Blueprints, etc. have the correct status). Date is month when deliverable including all closeout material defined in the CARD have been produced.
  • www.linaro.org Upstream Development Roadmap Card Symbols Roadmap Symbol JIRA state Meaning Approved Planned >6 months out: either for a developer to start work or a dependency to become available (board, model, etc.). This has been reviewed by SC or OPSCOM and Approved for development when dependencies are made. Scheduled Work is scheduled to start to happen in the current or next interval. This has been reviewed by SC or OPSCOM for work in the interval. Upstream Development Iterating with upstreams (project or distribution) for inclusion. Recreating patches, rerunning tests, adjusting documentation and submitting until acceptance. Closed (Delivered) Date is usually based on external cycle of project or distribution. Date is month when deliverable including all closeout material defined in the CARD have been produced.
  • www.linaro.org Ongoing Roadmap Card Symbols Roadmap Symbol JIRA state Meaning Approved Approved to start after current interval : either for a developer to start work or a dependency to become available (board, model, etc.). This has been reviewed by SC or OPSCOM and Approved for development when dependencies are made. Scheduled Planned to start in current or next interval: either for a developer to start work or a dependency to become available (board, model, etc.). This has been reviewed by SC or OPSCOM and Approved for development when dependencies are made. Development Development is ongoing, developer(s) active. The code, documentation and regression test cases to verify the code are being created. Periodic deliverables are being produced as needed. End of arrow goes to end of displayed slide. Closed (Delivered) SC or OPSCOM determines that work on effort should stop. Arrow ends when work stops on task.
  • www.linaro.org Q3 Q4 Q1 Q2 FutureQ3 Q4 2013 2014 Linaro Enterprise Group (LEG) Roadmap SATA v7UEFI v7 Hyp boot UEFI v8 validate core GRUB ACPI LAVA January 2014 LAVA multiboot for XEN SMBIOS stub Runtime GNUEFI KVM XEN BDS mem map SATA v8 secure boot PCIe QEMU Network boot Runtime stub SMBIOS mach-virt UEFI v8 FDT cfg table XEN stub
  • www.linaro.org Kernel Enhancements Q3 Q4 Q1 Q2 FutureQ3 Q4 2013 2014 Linaro Enterprise Group (LEG) Roadmap ACPI January 2014 UEFI services LAVA RAS kernel rebasing FVP tables PM states Hyp Core v8 Driver APEI Perf Daemon VFP/NEON perf+unwind kernel subsystem profiling feature parity GUFI
  • www.linaro.org Builds and Baselines Optimizations HipHop App Server OpenJDK Q3 Q4 Q1 Q2 FutureQ3 Q4 2013 2014 Linaro Enterprise Group (LEG) Roadmap Fedora C1 CRC v8 OpenStack v7 Calxeda OpenStack v8 OpenSSL v7 LAMP profiling v7 Performance evaluation JTREG CI January 2014 OpenStack Use Cases OpenStack CI LAVA Hadoop SPECjbb 2013 JCK step 1 HHVM JIT C2 maintainance and optimization OpenSSL v8 golang gcc golang gc Assembly dep stage 1 Hugepages v7 v8
  • www.linaro.org Linaro Processes: further reading ● https://wiki.linaro.org/Process/Roadmap/Key ○ How to decipher the generated roadmaps. ● https://wiki.linaro.org/Internal/Roadmaps/Process ● https://wiki.linaro. org/Internal/OPSCOM/RoadmapProcessWithJIRA ○ Has more detailed state diagrams ○ Has information model ○ Has standard templates NOTE: documentation updates are “in progress”, and we'll aim to keep these sites up to date with any further process tuning.
  • www.linaro.org Linaro Roadmaps: publishing status ● site: https://wiki.linaro.org/Internal/TSC/Roadmaps ● Approved (under OPSCOM review): ○ Engineering: Toolchain, Kernel, Graphics, Virtualization, Android, Power Management ○ Platforms: LAVA, QA, Builds & Baselines ○ Linaro Enterprise Group (LEG) ○ Linaro Networking Group (LNG) ● In Development (subject to TSC approval): ○ Security - draft in discussion, voting soon. ○ Infrastructure - draft in discussion, voting soon.
  • More about Linaro Connect: http://connect.linaro.org More about Linaro: http://www.linaro.org/about/ More about Linaro engineering: http://www.linaro.org/engineering/ Linaro members: www.linaro.org/members
  • www.linaro.org Information for a well formed request ● Overview: 1 line description of what is being requested. ● Details: Description, with links to relevant information, and contacts to help clarify roadmap request. ● Confidentiality Level: Private, Linaro+SC ○ is there member confidential data in this request? ○ can it be shared with other members? ● Source: Who made original request? ● Member(s) Interest Level: Sponsor(s)? ● Date needed by? (if known)
  • www.linaro.org Steering Committee (SC) Role: ○ Member nominees provide guidance on priorities for technical resources. Responsibilities: ○ Formal sponsorship of roadmap requests ○ Review and prioritize strategic new efforts and changes at EPIC level (>3 person months of effort) ○ Periodic review of ongoing activities ○ Roadmap publishing scope determination ○ Topic roadmap approval Meets: ○ Every 2 weeks.
  • www.linaro.org Operational Sub Committee (OPSCOM) Role: ○ Member nominees provide tactical feedback implications of roadmap changes Responsibilities: ○ Review new roadmap CARDs in approved EPICs ○ Review closeout material on CARDs for issues. ○ Review changes to CARDs (state & date), and provide feedback if there are implications to projects that members have a dependency on. Meets: ○ Start of month, on week TSC does not meet. Documented: https://wiki.linaro.org/Internal/OPSCOM/RoadmapProcessWithJIRA