Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 4 Next »

Goals of this effort

  • Define what conditions are required to met before AGL declares a long-term support version
  • Define what will be maintained as part of an LTS version and what AGL device creators can expect from AGL LTS. 
  • Estimate the costs of an LTS so the AB is aware of the long-term commitment. 

Current situation - Releases are supported for 6  - 9 months with patch updates, typically 4 - 6 updates per release.  

Patch updates (AGL 6.0.1 to AGL 6.0.2) may include:

  • Minor Yocto version updates (e.g. 2.6.1 to 2.6.2)
  • Security fixes
  • Fixes to AGL Services and Apps. 
  • New reference apps
  • BSPs for new reference or community boards
  • Updated BSPs for existing reference or community boards

Patch updates do not include:

  • Major Yocto version updates (e.g., 2.6.2 to 2.7.0 or rocko to sumo)
  • Updates to stable AGL APIs

Minor version updates (AGL 6.0.2 to 6.1.0) may include 

  • Minor Yocto version updates (e.g. 2.6.1 to 2.6.2)
  • Updates to stable AGL APIs
  • Fixes to AGL Services and Apps
  • BSPs for new reference or community boards
  • Updated BSPs for existing reference or community boards


Stated desired for declaring a LTS version for 4-5 years of support

  • 2-3 years prior to start of production, then 2 - 3 years of support post SOP.
  • Will declare an LTS once every two to three years at maximum.
  • Advisory Board approval required for an LTS to be declared since it requires a serious long-term funding commitment


Requirements and Assumptions for an LTS version of AGL 

  • Need to limit the number of hardware platforms that are supported for the LTS version only to the boards that are being put into production by members. 
    • Limit to Reference Hardware System Architecture compliant architectures?
    • Instrument cluster reference hardware?
  • Probably want to limit which components are maintained. For example bluez may not be included because it is a replaceable component that we think will be used by the device creators. 
  • AGL demo may not be maintained but we still need to build a binary that runs on the supported platforms so that we can test it. 
  • APIs will be stable over the lifetime of the LTS version. 
  • Need a strategy for how to accept patches into the LTS that may be different from the development model we use today. 
  • Gain agreement from commercial stakeholders, especially SOC vendors, that they will support the AGL LTS. 
    • For SOC vendors this will requirement an agreement to maintain their BSP, kernel version, and graphics stack for the life of the LTS.
    • For OEM and Tier One members this will requirement an agreement that they will contribute fixes back to the AGL LTS effort. 


General LTS in open source industry

  • Not done by the project itself beyond two years typically. Usually is taken over by a commercial company
  • Yocto provides no long-term support beyond 18 - 24 months. Usual expectation is that a commercial company can be contracted to maintain packages beyond that time-frame. 


Next Steps

  • Gather and consolidate requirements for review by the SAT and TSC by the June 6 SAT call. Team will consist of Walt, Panasonic, Denso, Toyota, VW, MB. 
  • No labels