arago top concept

Layer guidelines

================

These guidelines apply to TI public OE/Yocto layers that are used by TI CoreSDK, 

specifically meta-ti BSP layer and meta-arago and its sublayers for Arago Distro 

and Apps. These may or may not apply to downstream product-specific layers.



1. BSP

meta-ti follows strict OE/Yocto requirements for BSP layers. Only BSP-related 

components and customizations are allowed. No Distro policies are allowed. No 

standalone or demo applications are allowed. Allowed list includes bootloaders, 

kernels, drivers, firmwares and any corresponding dependencies, such as 

toolchains or user-space config utilities. And platform/machine definitions.



Changes in BSP layer should not affect core recipes when building for other 

platforms. E.g. adding meta-ti to the layer stack and building for non-TI 

platform should not trigger TI customizations. There are 2 main ways to do this:



a) define a new provider for a core recipe and set PREFERRED_PROVIDER in either 

machine config or distro config. Example: linux-ti-staging and linux-ti-mainline 

are some of the many providers for virtual/kernel. Same with u-boot-ti-staging.



b) if using bbappend to alter a core recipe, no variable should be changeed 

directly. Any change in a bbappend should be guarded by an override - either 

machine, arch or soc override. Examples: SRC_URI_ti-soc = "git://git.ti.com/..." 

or SRCREV_k3 = "abcdef"





2. Distro

meta-arago consists of 2 sublayers - meta-arago-extras for TI Applications and 

meta-arago-distro for Arago Distro policies.



meta-arago-extras may cary TI-developed apps, plus any TI-customizations or 

integration changes against core recipes, as long as those are not specific to 

Arago Distro or TI-SDKs and may be useful to other distros when used with TI 

platforms from meta-ti. Examples: gstreamer TI integration, wayland/weston TI 

integration. But efforts should be made to upstream those integrations into 

corresponding projects.



meta-arago-distro contains all the policies, such as setting preferred versions 

and providers, modifying DISTRO_FLAGS and PACKAGECONFIGs, defining packagegroups 

and images for CoreSDK.





3. Deprecation

Platforms and recipes should be maintained. That means any breakage should be 

addressed in a timely fashion. If there is no maintainer (or assigned developer) 

for a platform or a recipe and they start causing breakage, layer maintainers 

are not expected to handle such issues on their own and may submit offending 

pieces for deprecation and removal. For more details see Maintenance Process 

section.





4. Product-related

CoreSDK provides full Linux stack necessary for end-customers to build their 

products on. Per the above definitions of meta-ti and meta-arago layers, this 

does not include Demo applications and/or any examples. Those should be moved 

to other downstream layers, e.g. SDK-specific ones like PLSDK or PSDKLA.





5. Maximum reuse

Upstream OE/Yocto core layers constantly add new features. CoreSDK layers should 

periodically (every LTS?) evaluate availability of new features and strive to 

replace any custom implementations with upstream alternatives. Examples: OOBE 

create-sdcard.sh -> wic images, srcipk -> archiver, AM-SDK devkit structure -> 

standard OE SDK, building non-Linux for other SoC cores with multiconfig, etc.





6. Yocto compliance

meta-ti has always been Yocto-compliant and carried "Yocto Compatible" badge. 

No changes should affect this status. This can be verified by yocto-check-layer 

script locally, which also runs periodically on the Yocto Project autobuilder.





Maintenance process

===================

The process closely follow and borrows from the Linux kernel community, its 

structure and trust model.



1. Layer maintainers

There should be 2 main layer maintainers, which are specified in the top-level 

README file:

https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/README



Layer maintainers are responsible for top-level patch reviews, gathering 

additional feedback from subject-matter expers (SMEs) and area/recipe 

maintainers before merging patches.





2. Area/recipe maintainers

Area/recipe maintainers are subject-matter experts (SMEs) for their specific 

areas of expertise. They help layer maintainers with patch reviews and oversee 

their recipes and subsystems - timely update to newer versions and address any 

issues or breakages.



Recipe maintaine should be defined by corresponding RECIPE_MAINTAINER variable 

inside the recipe, or globally in the maintainers.inc file, similar to OE-Core:

https://git.openembedded.org/openembedded-core/tree/meta/conf/distro/include/maintainers.inc





3. Submitting and reviewing patches

Patch submission process follows the same for the Linux kernel - patches are 

submitted to public mailing lists for review, merged by layer maintainers:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html



Each layer has own public mailing list:

meta-ti@lists.yoctoproject.org - https://lists.yoctoproject.org/g/meta-ti

meta-arago is currently migrating from arago-project.org to yoctoproject.org



Submitted patches must be signed - see "Sign your work - the Developer’s 

Certificate of Origin" section of Linux kernel submitting-patches link.



Additional fields in the patch are also allowed and encouraged during submission 

and review process - see "When to use Acked-by:, Cc:, and Co-developed-by:" and 

"Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:" sections





4. Recipe maintainers participation

Recipe maintainers are expected to review someone else's patches that modify 

recipes they are responsible for. They are encouraged to provide their feedback 

and mark patches with necessary Tested-by:, Reviewed-by: or Acked-by: fields.