> -----Original Message----- > From: [email protected] [mailto:meta-freescale- > [email protected]] 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 _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
