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.
...
- 2-3 years prior to start of production, then 2 - 3 years of support post SOP.
- Would 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.
- Probably want to limit which 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.
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