The purpose of the integration flow is to define development and release processes for AGL distribution. Integration flow is the corner stone which defines responsibility split and cooperation between Subsystem teams.

Release cycle consists of Development phase and Integration phase

Previous AGL distribution release is available in AGL git.

Software development is performed by a Subsystem team (see [3] ) against the latest AGL distribution release delivered by Build, Tools and Release Engineering team (see [3], [4] ) according to the below scope:

• Components/packages and corresponding recipes assigned to a Subsystem team [here link to AGL wiki page with package split between Subsystem teams ←missing on wiki at the moment]
• Components/packages and corresponding recipes for any dependencies involved

• Source code for components/packages, patches and corresponding recipes are available and tagged for release in a git infrastructure accessible by Build, Tools and Release Engineering team (see [3], [4] )
• Component Release Notes with the following content
• URI to source code repository
• Feature set or changelog
• AGL distribution release used for development o Compile time and runtime dependencies
• Links to any related AGL Jira entries
• Unit tests run or needed to be run
• Host OS used for development, output of ‘uname –a’

See section ??? 

Build, Tools and Release Engineering team (see [3], [4] ) integrates artifacts created by Subsystem teams during development phase of the cycle.

Build, Tools and Release Engineering team (see [3], [4]) may develop a proposal to reject or postpone integration of artifact(s) developed by Subsystem team for the cycle based on number of conflicts between the packages requested for integration by the Subsystem teams, release cycle timeline and resources available in the team.

Build, Tools and Release Engineering team (see [3], [4]) delivers the proposal to SAT for approval/adjustment.

Build, Tools and Release Engineering team (see [3], [4] ) to develop and publish test spec for the release Build, Tools and Release Engineering team (see [3], [4] ) to perform testing according to the test spec for the release

Build, Tools and Release Engineering team (see [3], [4] ) to create entries in AGL Jira for failed tests and assign the issues to Subsystem teams after triaging (if needed).

AGL git repository infrastructure and AGL Distro Release notes that are tagged as the next AGL distribution release and enable to perform a successful build which results in producing the following on filesystem of host development machine:

• bootloader binary
• device tree blob
• kernel binary
• rootfs binary

Test result report and Jira entries for failed tests

Announcement of the release availability by Overall Maintainer [3]

Release planning to be done by SC and/or SAT.

Release project management to be performed by SC/SAT in cooperation with Overall Maintainer [3] 

AGL SC and SAT decided to use Yocto 1.7 version for development until Jan 2016, see [1].

Initial AGL Distribution Release to be done by Build, Tools and Release Engineering team (see [3], [4] )

Bitbake target agl-image-mininal on AGL meta-agl git state as of [2] to be used as AGL distribution release v0.1. The release v0.1 to be built for Renesas Porter board. Only smoke testing (booting into command line shell prompt) to be performed for the Initial release.

Reference documents: [1] https://wiki.automotivelinux.org/project-create-agl-distro/phase_1#issue_- _how_to_create_meta-agl_layer rev 2015/07/31 02:16

[2] https://git.automotivelinux.org/gerrit/gitweb?p=AGL/meta- agl.git;a=commit;h=ae2390f3adace68083ec7867193520611ecbf2eb

[3] https://wiki.automotivelinux.org/agl-distrorev2015/07/3102:31

[4] https://wiki.automotivelinux.org/subsystem/agl-build-releaserev2015/07/2113:46