Arago and OE alignment strategy

This page is intended to outline the strategy to keep Arago plans aligned with OpenEmbedded (stable & unstable branches). It is being done in public so that the community can comment on it via the Talk:Arago and OE alignment strategy page.

At present Apps Processors Software Apps is largely contributing Bitbake recipes to the OpenEmbedded mainline whilst the DVSDK Engineering teams are working in Arago. This is not a big problem except for the fact that we want to avoid duplication, getting out of sync etc.

For example at first there was a plan to refactor the current recipes from OpenEmbedded (unstable branch) at http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/ti to sub-directories for multimedia, DSP etc i.e. http://arago-project.org/git/people/?p=sajesh/arago-dvsdk-integration.git;a=tree;f=recipes;h=784eea75913f17f8479b130341c95284e4d282fa;hb=e70cb1938e038c6adc47987aac57652320131654. However this plan has now been eliminated to avoid discontinuities with existing OE recipes/ti users. Several customers have already gone to market with the latter even though at the time (Oct '09) there has been no TI System Testing on these recipes in DVSDK program context.

The key goals of this OE/Arago alignment are: -
 * enable community and other TI developers to jointly develop recipes and integrate content for other platforms regardless of the platforms being system-tested in the "next DVSDK release". For example enable developers to make progress on DM644x even though DVSDK 3.10 is primarily focused on DM355, DM365, DM6467.
 * enable "power-users" to run with what we have on a given platform even though it may not yet have been System Tested and formally released i.e. work with the community to get feedback on DM355, DM365, DM6467 as it's being developed. Just need to set expectations that things may change (hence usage of OE unstable branch)
 * frequent sync's OE <-> Arago (both ways) [frequency = TBD]
 * sync of OE mods back to Arago will ensure that DVSDK-Eng team can see any quality mods that the community have made to recipes/patches & thus DVSDK-Eng can take advantage of this.
 * sync of Arago bitbake recipes upstream to OE (excluding the 'legacy' dirs) so that standard OE users (of which there are many) can use TI-accelerated content.
 * doing this frequently increases the chances that patches & recipes will be accepted.
 * Arago uses a different toolchain (CodeSourcery 2009q1 as of Oct '09) than Angstrom - need to ensure that "standard packages" work in Arago - see X11-image as a proof of this.
 * It would be helpful as a confidence factor to see this topic updated to indicate what run-time testing was done here (i.e. basic sanity test of N out of M packages).
 * If a given package fails in Arago (but works in OE) what are the next steps?
 * Also need to document known limitations e.g. mplayer uses some advanced features only present in recent Angstrom gcc toolchain hence will not work at present in Arago w/ CS2009Q1.
 * enable Ease Of Use contributions
 * e.g. to make downloads, install, usage easier various scripts - for example http://arago-project.org/git/people/?p=brijesh/arago-dvsdk.git&a=blob_plain&f=bin/arago-install-net.pl and arago-build.pl help with downloading and building images etc. These should be considered for integration.
 * Narcissus - http://www.angstrom-distribution.org/narcissus/ - this is a slick online tool to create a so called 'rootfs' images for your favourite device. The wizard guides you through the basic options and will let you select the additional packages you want.
 * We may need something like this for Arago - or at least the ability to mix & match i.e. base/stable Arago drop with the ability for users to add OE packages on top.
 * do everything "in public"
 * let customers know our plans - if there's 1 thing I hear consistently it's "pls let us know progress/status/roadmap" - customers love http://tiexpressdsp.com/index.php?title=Codec_Engine_Roadmap for example.
 * OE users/community (naturally) do everything via public-mail lists, IRC channels - need to do likewise w/ DVSDK 3.10. For example there are key customers that want to track, get-started on DM6467, DM365 even before it has been system-tested.

Notes
 * we [TI] also submit OE recipes and patches in OMAP3 Graphics context - see http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/powervr-drivers. We agreed that this is fine i.e. do not need to work in Arago directly for this - there are no mis-alignment possibilities since DVSDK-Eng is not working on Graphics.
 * need to know which tree all of the user contributions are merged into e.g. where can we find the resultant Arago merge that includes e.g. http://arago-project.org/git/people/?p=sajesh/arago-dvsdk-integration.git;a=blob;f=recipes/ti/ti-codecs-dm365.bb;h=81e0999b4ef05c8b732eb8adadcafcaf7f06b6b7;hb=HEAD
 * 1 concern raised was "component developers won't want to have to maintain their recipes on weekly basis i.e. shouldn't sync's be less frequent to avoid TI component team X breaking DVSDK builds?". Response was that hopefully any discontinuities will get caught early by TIers active in the community & the community themselves.