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

[Luo Zhenhua-B19537]

> -----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.

> > * 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. 

> > * 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. 

> >  * 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. 

> >  * 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. 


Best Regards,

Zhenhua