[meta-freescale] Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Luo Zhenhua-B19537]

> -----Original Message-----
> From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-
> bounces at yoctoproject.org] On Behalf Of Otavio Salvador
> >>>>
> >>>>   It is not clear from the description what it would have inside.
> >>>> If it are going to have poky and all other layers the name is
> misleading.
> >>>> freescale-sdk or freescale-yocto-sdk would be better. Could you
> >>>> clarify it?
> >>>
> >>> I like the idea of meta-freescale-yocto-sdk since we are based on
> that.
> >>
> >> It all depends if it will provide poky or not. If it does, meta
> >> prefix ought to be dropped. meta prefix is used for layers and not
> >> complete SDKs so it will be confusing.
> >
> > We have used poky in the past on the ppc side, what are you thoughts
> here?
> 
> It all depends on what Freescale wants to offer to the customers. I see
> the possible options:
> 
>  1) reference SDK
> 
>     mostly as done by fsl-community-bsp however with meta-fsl-ppc, meta-
> fsl-multimedia and meta-fsl-networking all enabled and without meta-fsl-
> arm-extra since the reference SDK should support just the FSL official
> boards. This should use Poky and meta-openembedded from
> git.yoctoproject.org and meta git.openembedded.org and have just what is
> possible to provide without forking those projects.
> 
>  2) meta-freescale
> 
>     A repository which merges other layers (meta-fsl-*). So users to use
> it would need to clone others as Poky and meta-openembedded for allow the
> use of it.
> 
>  3) full supported SDK
> 
>    A full supported SDK which might be done as fsl-community-bsp however
> which uses forks of Poky / meta-openembedded with not merged stuff.
> 
> Personally I don't like option number 2 as it just confuse users in my
> point of view.
> 
> I'd go with option number 1 as it reduces the amount of code which FSL
> needs to support and allow more reuse of work. I understand sometimes it
> will slow down things as some changes/improvements might be blocked by
> release schedule of Yocto but it still seems like the natural choice for
> me.
> 
> The option number 3 seems over complicating things as it will be forcing
> FSL to maintain a fork of stuff and it has several implications (QA,
> security, documentation and so on).
> 
> Those are the options *I* see; someone might see other alternatives as
> well. In any case, it is important to understand how FSL intend to work
> in this point as each option has pros and cons.
[Luo Zhenhua-B19537] I agree option 1 is the most ideal way. However we have to maintain a local copy for poky/meta-oe in FSL internal git server due to some fixes can't be accepted and applied by opensource to meet FSL SDK release schedule, especially for last-time host fixes. 
    So we use option 3 for FSL PPC SDK releases. 


Best Regards,

Zhenhua