[meta-freescale] The updated proposal of FSL Yocto layers reorg - 4-Mar

[Otavio Salvador]

On Thu, Mar 7, 2013 at 4:32 AM, Luo Zhenhua-B19537 <B19537 at freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador at gmail.com [mailto:otavio.salvador at gmail.com] On
>> Behalf Of Otavio Salvador
>> >
>> >   Following SDK specific layers are maintained in git.am.freescale.net
>> > and git.freescale.com
>> >
>> >     meta-fsl-toolchain: layer for fsl toolchain recipes
>> >
>> >     meta-fsl-multimedia: layer for multimedia SDK
>> >
>> >     meta-fsl-networking: layer for networking SDK
>> >
>> >     meta-fsl-layerscape: layer for layerscape SDK
>>
>> I thought meta-fsl-layerscape would merge with meta-fsl-networking and
>> BSP part to be in meta-fsl-arm (as Vybrid).
> [Luo Zhenhua-B19537] multimedia, networking and layerscape are for different SDKs specific bits. The common recipes will be put into meta-fsl-ppc and meta-fsl-arm, including BSP part(e.g. machine conf, u-boot, kernel, etc). Please elaborate if I don't fully follow your comments.

I understand now but could you give an example of specific thing which
would go to layerscape layer?

>> > * Layer of getting layers specific to Freescale SDK
>> >
>> >   * Layer name: meta-freescale-sdk
>> >
>> >   * The function of this layer is similar as
>> > https://github.com/Freescale/fsl-community-bsp-platform and it is
>> > maintained in FSL internal/external git tree
>> >
>> >   * A branch is created for each FSL SDK release to include the
>> > scripts to fetch necessary layers of specified version
>>
>> It is still not clear to me what would be included here. Can you please
>> give a example directory structure for reference?
> [Luo Zhenhua-B19537] This layer is same as https://github.com/Freescale/fsl-community-bsp-platform, a manifest and a README are included.

In this case the naming is bad. I'd call it fsl-sdk or fsl-bsp. The
meta prefix is used for layers and it is not going to be the case as
it will be a ready to use solution which groups a set of layers.

>> > * U-boot/Linux on FSL official git tree (git.freescale.com)
>> >
>> >  * The source in git.freescale.com will be updated when SDK is formally
>> released, since full verification should be conducted to ensure quality.
>> So Kernel in FSL official git tree will not be synced with internal git
>> tree during the developing phase.
>>
>> This is bad specially because people end redoing a lot of work which has
>> already been done. If you could make it public but marked as experimental
>> it'd be great as it would allow more people to help to track down
>> possible issues and would make the development more community friendly.
> [Luo Zhenhua-B19537] I understand your concern. This might be related to the FSL source code delivery/upstream process, we can have further internal discussion.

That'd be good. It'd make contributions much easier from/for the community.

>> >  * The kernel team can't have everything upstreamed for an SDK release
>> and supporting all feature and bug fixes. Besides we will pick a kernel
>> and test and fix it so it will always fall out of sync. (e.g. latest
>> kernel release - 1 release + fixes).
>>
>> Sorry, I fail to understand what you mean here. Do you mind to explain it
>> to me?
> [Luo Zhenhua-B19537] Not every kernel patch in FSL SDK can be upstreamed timely due to different reasons.

Well due license compliance point of view it do need to be make
available after you give it for a partner/customer as it is the start
of the distribution phase. I understand some changes does need much
more time for review and proper testing but if those could go to a
specific branch or tree which is widely known it is not official
release and not supported, it might alleviate the problem.

>> >  * These should be much closer to the same for the layers we control.
>> Due to the limited resources spread around, we can't always get all fixes
>> in the oe-core/poky for an SDK release timely. But a lot of times we can
>> get them into the branch for that release and eventually a point release.
>> Upstream/public branches will try to work with all Yocto releases, while
>> SDK releases could contain a lot of hacks to more things working.
>>
>> Yes I think a level of divergence is unavoidable but it should be kept at
>> minimum.
> [Luo Zhenhua-B19537] Agree to minimize the gap.

Regards,

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br