- Repeatable builds
- License traceability and formal distribution of required source code
- Use "GPLv2 only" version of OE and Poky?
- Is Yocto's built in license manifest support sufficient for AGL delivery or do we need to run FOSSology on our releases? The OEM and/or Tier One will need to run their own scanners anyway since they are responsible for the final product release that is delivered to their customer.
- Test reports available for releases at a component level
- Long-term support of AGL releases available
- SDK with IDE/GUI for application developers.
- Documentation about how to use AGL to create a production system
- Complete documentation of AGL components and APIs
- What functionality is required by OEMs? Is there a gap we need to cover that is not in our current roadmap?
- What patent information would we need to provide? Is providing a list of components to OIN sufficient or it there some other work members expect AGL to provide? BSP should be OSS with support provided by the SOC vendor. Production BSPs provided to device creators by SOC vendors need to be shared with AGL to enable validation against the AGL software.
To do
- Ideally each OEM and/or Tier One provides an analysis of the AGL components they are considering using in their mass production systems. The analysis would include whether they plan to include the component and the current status of the component with respect to their product plan. If there are gaps that need to be filled AGL can than consider how to fill those gaps.
- Current Toyota products using AGL do not use AGL directly, but they take in AGL and modify it. What lessons has Toyota learned that we can apply to AGL that would allow them more directly use AGL.
- Denso Ten has performed a comparison of the current AGL API available (200+) to their current production platform (1000+). Denso Ten will provide this analysis later this year once it has been translated from Japanese.