...
- Code Maintained Upstream of AGL
- 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.
- Need a strategy for how to accept patches into the LTS that may be different from the development model we use today.Can only accept upstream components into AGL that are maintained in a reproducible manner (this is an impossible requirement to meet today. Yocto is working on making their builds reproducible but the feeling is that they may be a year away from that goal. In particular we are interested in core-image-weston from Yocto.)
- 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 AGL LTS version.
- For OEM and Tier One members this will requirement an agreement that they will contribute fixes back to the AGL LTS effort.
...
- Code Maintained by AGL
- Source code and recipes will be maintained in such a way that builds are reproducible over the lifetime of the LTS version.
- Host system will be limited to the container that is shipped with the initial LTS version. AGL will ensure that the container is supported on the latest host system. (i.e. As Fedora or other distributions evolve the AGL container will still be able to be built)
- 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.
- Test Test image or images that allow AGL to be tested
- Once we have defined the APIs that are supported in the AGL LTS we can use the recipes to derive the upstream packages that need to be tested maintained and reproducible.
- APIs will be stable over the lifetime of the LTS version.
- Security patches and bug-fixes will be backported from latest AGL version to LTS version.
- Source code and recipes will be maintained in such a way that builds are reproducible over the lifetime of the LTS version.
...
- Hardware Considerations
- 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?
- AGL devices manufacturers are responsible for maintaining BSPs for their production hardware.
- 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.
- Other Considerations
- Governance of the LTS version. How are decisions made as to when an LTS is declared, what is maintained as part of the LTS version, when does LTS go EOL, approval of releases, etc.
- Patch workflow - Need a strategy for how to accept patches into the LTS that may be different from the development model we use today.
- Cost and funding by the AGL Advisory Board over the lifetime of the LTS.
General LTS in open source industry
...