Please review the proposal of FSL Yocto layers reorg

Please review the proposal of FSL Yocto layers reorg

[Luo Zhenhua-B19537]

[-- Attachment #1.1: Type: text/plain, Size: 188 bytes --]

Hello Otavio and all,

The FSL Yocto layers reorg proposal is attached, can you please take a look? Any comment and suggestion is welcome and appreciated.


Best Regards,

Zhenhua

[-- Attachment #1.2: Type: text/html, Size: 4844 bytes --]

[-- Attachment #2: FSL_Yocto_Layers_Reorg_26-Feb.pptx --]
[-- Type: application/vnd.openxmlformats-officedocument.presentationml.presentation, Size: 682266 bytes --]

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> Hello Otavio and all,

Hello,

I appreciate you'd like our input on this.

> The FSL Yocto layers reorg proposal is attached, can you please take a look?
> Any comment and suggestion is welcome and appreciated.

Please next time avoid sending a huge PPT file; instead send a small
set of jpeg images or a PDF. Anyway, here goes my comments:

 * duplicated packages between i.MX and QorIQ BSPs

   The best way to avoid duplication is to upstream those recipes in
oe-core/meta-oe/meta-virtualization/... and just use this layers

 * naming of Layers

   I'd prefer to rename the layer, if we decide to do that, as soon as
possible as the more time we wait, more users will be confused. So in
case we choose to go with meta-fsl-imx, it ought to be done in a way
meta-fsl-arm keeps working for current users and also to not break
current BSPs so a migration plan needs to be done.

Now let's focus in Stage 2:

 * Following 4 repositories are maintained in git.am.freescale.net,
git.freescale.com and git.yoctoproject.org (meta-fsl-imx,
meta-fsl-vybird, meta-fsl-qoriq and meta-fsl-layerscape)

   It is not clear how will be the development flow. Which server will
be the official repository? The git.yoctoproject.org one?

   I'd like to avoid the huge pile of patches for review and merging
as we've seen done in PPC. This does not scale and makes it harder to
avoid work duplication.

   Are Freescale engeneers going to work in public repositories?

 * meta-freescale unified

   Putting another layer where things will be duplicated will make the
documentation and support harder. We'll have users asking questions
which are specific to meta-freescale and does not fit in usual layers
use and it is unavoidable that end users will need to use other layers
to accomplish their needs so I see no reason to differ from regular
use here. In my point of view, the use of a 'repo' (as we done in
fsl-community-bsp) is the way to go as you can provide a well tested
BSP combination, ensure users have a user friendly environment and do
not disrupt the way of working used in usual layers use.

   I've been using 'repo' layout with customers and it does work quite
 well as it makes trivial for users to use Yocto.

 * branch/tagging policy

   The maintainence policy we have for the branches are the same as
Yocto and thus the branching and tagging will follow the Yocto
branching and tagging. This is another reason why I think the use of
'repo' might be good as it allow for tagging of the 'repo' manifest to
make releases.

 * SCM

   I use Gerrit internally for customers work and I also think it is a
good addition for internal work however please don't use it for public
layers work. As I said before, people tend to have a huge set of
patches before sending to upstream merge and this makes things harder
for everyone. Public repositories ought to be the ones used for
internal development (except when new SoC or similar is being done).

Regards,

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

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Tue, Feb 26, 2013 at 2:15 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> Hello Otavio and all,
>
> The FSL Yocto layers reorg proposal is attached, can you please take a look?
> Any comment and suggestion is welcome and appreciated.
>

1) Don't cross post to internal and external mailing lists.

2) I still don't really see the point in renaming from meta-fsl-ppc ->
meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
what others think about this. It seems like unneeded changes that will
just cause confusion. Why not just put vybird in meta-fsl-arm?

3) I think we should delay the creation of some of these layers until
we really have packages that are duplicated between two layers (e.g.
meta-layerscape can wait until we have a recipe that is needed for
both ARM and PPC and is not upstream in another layer)

4) I think we need some more info about the "unifed" layer. I don't
think it needs to exist yet, but maybe others would like to see it.
Personally, I think it can be created automatically much like poky is
now.

-M

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Tue, Feb 26, 2013 at 9:05 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537
> <B19537@freescale.com> wrote:
>> Hello Otavio and all,
>
> Hello,
>
> I appreciate you'd like our input on this.
>
>> The FSL Yocto layers reorg proposal is attached, can you please take a look?
>> Any comment and suggestion is welcome and appreciated.
>
> Please next time avoid sending a huge PPT file; instead send a small
> set of jpeg images or a PDF.

Or just plain text is probably more appropriate.

> Anyway, here goes my comments:
>
>  * duplicated packages between i.MX and QorIQ BSPs
>
>    The best way to avoid duplication is to upstream those recipes in
> oe-core/meta-oe/meta-virtualization/... and just use this layers

Agreed, but there are some FSL specific packages that might no be
appropriate for meta-oe. One example is a user space networking stack
that runs on ARM and PPC but only on FSL hardware. Where would that
go?

>  * naming of Layers
>
>    I'd prefer to rename the layer, if we decide to do that, as soon as
> possible as the more time we wait, more users will be confused. So in
> case we choose to go with meta-fsl-imx, it ought to be done in a way
> meta-fsl-arm keeps working for current users and also to not break
> current BSPs so a migration plan needs to be done.

Is there really a major reason to change the names though, does it add
clarity? Maybe, so I'd like more discussion on this.

> Now let's focus in Stage 2:
>
>  * Following 4 repositories are maintained in git.am.freescale.net,
> git.freescale.com and git.yoctoproject.org (meta-fsl-imx,
> meta-fsl-vybird, meta-fsl-qoriq and meta-fsl-layerscape)
>
>    It is not clear how will be the development flow. Which server will
> be the official repository? The git.yoctoproject.org one?

External, they exist for workflow reasons right now (e.g. we need to
test these builds before submitting external). These bits really
should not be under discussion, since we are address the community
facing repos in this discussion. In addition we are trying to make
more components available externally as well.

>    I'd like to avoid the huge pile of patches for review and merging
> as we've seen done in PPC. This does not scale and makes it harder to
> avoid work duplication.

Ideally, but there is no guarantees to make here. Priority's and
resources are always shifting around.

>    Are Freescale engeneers going to work in public repositories?

All work should be submitted to external repos right away and we
should not be waiting. So internally we are testing against master
branches of all external repos.

>  * meta-freescale unified
>
>    Putting another layer where things will be duplicated will make the
> documentation and support harder. We'll have users asking questions
> which are specific to meta-freescale and does not fit in usual layers
> use and it is unavoidable that end users will need to use other layers
> to accomplish their needs so I see no reason to differ from regular
> use here. In my point of view, the use of a 'repo' (as we done in
> fsl-community-bsp) is the way to go as you can provide a well tested
> BSP combination, ensure users have a user friendly environment and do
> not disrupt the way of working used in usual layers use.
>
>    I've been using 'repo' layout with customers and it does work quite
>  well as it makes trivial for users to use Yocto.

repo could work here, or git submodules, or many other ways. I think
adopting repo is a good idea since the arm side is already using it in
a public way.

>  * branch/tagging policy
>
>    The maintainence policy we have for the branches are the same as
> Yocto and thus the branching and tagging will follow the Yocto
> branching and tagging. This is another reason why I think the use of
> 'repo' might be good as it allow for tagging of the 'repo' manifest to
> make releases.
>
>  * SCM
>
>    I use Gerrit internally for customers work and I also think it is a
> good addition for internal work however please don't use it for public
> layers work. As I said before, people tend to have a huge set of
> patches before sending to upstream merge and this makes things harder
> for everyone. Public repositories ought to be the ones used for
> internal development (except when new SoC or similar is being done).

I don't think this will be public. It's sort of an internal bit that
got shared. We will keep posting patches to meta-freescale for review
and then they will be applied.

-M

>
> Regards,
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Tue, Feb 26, 2013 at 6:29 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Feb 26, 2013 at 9:05 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537
>> <B19537@freescale.com> wrote:
>>> Hello Otavio and all,
>>
>> Hello,
>>
>> I appreciate you'd like our input on this.
>>
>>> The FSL Yocto layers reorg proposal is attached, can you please take a look?
>>> Any comment and suggestion is welcome and appreciated.
>>
>> Please next time avoid sending a huge PPT file; instead send a small
>> set of jpeg images or a PDF.
>
> Or just plain text is probably more appropriate.
>
>> Anyway, here goes my comments:
>>
>>  * duplicated packages between i.MX and QorIQ BSPs
>>
>>    The best way to avoid duplication is to upstream those recipes in
>> oe-core/meta-oe/meta-virtualization/... and just use this layers
>
> Agreed, but there are some FSL specific packages that might no be
> appropriate for meta-oe. One example is a user space networking stack
> that runs on ARM and PPC but only on FSL hardware. Where would that
> go?

This seems like a BSP package in this case as it is enabling a hw
feature. Even not being a SoC support package it adds features to the
SoC so seems to fit the BSP layer.

>>  * naming of Layers
>>
>>    I'd prefer to rename the layer, if we decide to do that, as soon as
>> possible as the more time we wait, more users will be confused. So in
>> case we choose to go with meta-fsl-imx, it ought to be done in a way
>> meta-fsl-arm keeps working for current users and also to not break
>> current BSPs so a migration plan needs to be done.
>
> Is there really a major reason to change the names though, does it add
> clarity? Maybe, so I'd like more discussion on this.

For me it doesn't. I think users would think easier to have layers per
architecture than by marketing name.

>> Now let's focus in Stage 2:
>>
>>  * Following 4 repositories are maintained in git.am.freescale.net,
>> git.freescale.com and git.yoctoproject.org (meta-fsl-imx,
>> meta-fsl-vybird, meta-fsl-qoriq and meta-fsl-layerscape)
>>
>>    It is not clear how will be the development flow. Which server will
>> be the official repository? The git.yoctoproject.org one?
>
> External, they exist for workflow reasons right now (e.g. we need to
> test these builds before submitting external). These bits really
> should not be under discussion, since we are address the community
> facing repos in this discussion. In addition we are trying to make
> more components available externally as well.

By external you mean which? git.yoctoproject.org?

Right but I think the tests will be done by the developer/engineer; in
case a tree is used for it, this tree could be something like
linux-next which merges people branches onto a tree and an autobuild
is triggered ...

>>    I'd like to avoid the huge pile of patches for review and merging
>> as we've seen done in PPC. This does not scale and makes it harder to
>> avoid work duplication.
>
> Ideally, but there is no guarantees to make here. Priority's and
> resources are always shifting around.

I understand but what I noticed from PPC pull requests is that they're
send basing in an old poky/oe-core/meta-oe snapshot and not
build/tested in current snapshots. This adds extra work for people
reviewing them as some might even be deprecated in today's upstream
tree.

I don't know the internal workflow but we might try to think a way to
improve the way those patches are handled so we have more often pull
requests and do a more incremental work.

>>    Are Freescale engeneers going to work in public repositories?
>
> All work should be submitted to external repos right away and we
> should not be waiting. So internally we are testing against master
> branches of all external repos.

Fully agree.

>>  * meta-freescale unified
>>
>>    Putting another layer where things will be duplicated will make the
>> documentation and support harder. We'll have users asking questions
>> which are specific to meta-freescale and does not fit in usual layers
>> use and it is unavoidable that end users will need to use other layers
>> to accomplish their needs so I see no reason to differ from regular
>> use here. In my point of view, the use of a 'repo' (as we done in
>> fsl-community-bsp) is the way to go as you can provide a well tested
>> BSP combination, ensure users have a user friendly environment and do
>> not disrupt the way of working used in usual layers use.
>>
>>    I've been using 'repo' layout with customers and it does work quite
>>  well as it makes trivial for users to use Yocto.
>
> repo could work here, or git submodules, or many other ways. I think
> adopting repo is a good idea since the arm side is already using it in
> a public way.

Another good point for it is that it is commonly used by people
working at Android so some people are aready used to it. Regarding git
submodules I didn't like it when we tried as it is very easy to make
bad things with it but it does solve same problem.

>>  * branch/tagging policy
>>
>>    The maintainence policy we have for the branches are the same as
>> Yocto and thus the branching and tagging will follow the Yocto
>> branching and tagging. This is another reason why I think the use of
>> 'repo' might be good as it allow for tagging of the 'repo' manifest to
>> make releases.
>>
>>  * SCM
>>
>>    I use Gerrit internally for customers work and I also think it is a
>> good addition for internal work however please don't use it for public
>> layers work. As I said before, people tend to have a huge set of
>> patches before sending to upstream merge and this makes things harder
>> for everyone. Public repositories ought to be the ones used for
>> internal development (except when new SoC or similar is being done).
>
> I don't think this will be public. It's sort of an internal bit that
> got shared. We will keep posting patches to meta-freescale for review
> and then they will be applied.


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

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Tue, Feb 26, 2013 at 6:21 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Tue, Feb 26, 2013 at 2:15 AM, Luo Zhenhua-B19537
> <B19537@freescale.com> wrote:
>> Hello Otavio and all,
>>
>> The FSL Yocto layers reorg proposal is attached, can you please take a look?
>> Any comment and suggestion is welcome and appreciated.
>>
>
> 1) Don't cross post to internal and external mailing lists.
>
> 2) I still don't really see the point in renaming from meta-fsl-ppc ->
> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
> what others think about this. It seems like unneeded changes that will
> just cause confusion. Why not just put vybird in meta-fsl-arm?

I support this idea and it'd make users' life much easier.

> 3) I think we should delay the creation of some of these layers until
> we really have packages that are duplicated between two layers (e.g.
> meta-layerscape can wait until we have a recipe that is needed for
> both ARM and PPC and is not upstream in another layer)

Personally I think it won't happen often as usually it'll not be a BSP
package that will fit in this set so it'll end in meta-virtualization
or meta-networking eventually.

> 4) I think we need some more info about the "unifed" layer. I don't
> think it needs to exist yet, but maybe others would like to see it.
> Personally, I think it can be created automatically much like poky is
> now.

As I said, I fear it adding more confusing than solving. It might
making users wonder which layer he/she will use and don't know exactly
the difference between the merged layer and the individual ones.

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

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Tue, Feb 26, 2013 at 3:43 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Feb 26, 2013 at 6:29 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Feb 26, 2013 at 9:05 AM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537
>>> <B19537@freescale.com> wrote:
>>>> Hello Otavio and all,
>>>
>>> Hello,
>>>
>>> I appreciate you'd like our input on this.
>>>
>>>> The FSL Yocto layers reorg proposal is attached, can you please take a look?
>>>> Any comment and suggestion is welcome and appreciated.
>>>
>>> Please next time avoid sending a huge PPT file; instead send a small
>>> set of jpeg images or a PDF.
>>
>> Or just plain text is probably more appropriate.
>>
>>> Anyway, here goes my comments:
>>>
>>>  * duplicated packages between i.MX and QorIQ BSPs
>>>
>>>    The best way to avoid duplication is to upstream those recipes in
>>> oe-core/meta-oe/meta-virtualization/... and just use this layers
>>
>> Agreed, but there are some FSL specific packages that might no be
>> appropriate for meta-oe. One example is a user space networking stack
>> that runs on ARM and PPC but only on FSL hardware. Where would that
>> go?
>
> This seems like a BSP package in this case as it is enabling a hw
> feature. Even not being a SoC support package it adds features to the
> SoC so seems to fit the BSP layer.

This was along the line of my thinking.

>
>>>  * naming of Layers
>>>
>>>    I'd prefer to rename the layer, if we decide to do that, as soon as
>>> possible as the more time we wait, more users will be confused. So in
>>> case we choose to go with meta-fsl-imx, it ought to be done in a way
>>> meta-fsl-arm keeps working for current users and also to not break
>>> current BSPs so a migration plan needs to be done.
>>
>> Is there really a major reason to change the names though, does it add
>> clarity? Maybe, so I'd like more discussion on this.
>
> For me it doesn't. I think users would think easier to have layers per
> architecture than by marketing name.

This was along the line of my thinking.

>
>>> Now let's focus in Stage 2:
>>>
>>>  * Following 4 repositories are maintained in git.am.freescale.net,
>>> git.freescale.com and git.yoctoproject.org (meta-fsl-imx,
>>> meta-fsl-vybird, meta-fsl-qoriq and meta-fsl-layerscape)
>>>
>>>    It is not clear how will be the development flow. Which server will
>>> be the official repository? The git.yoctoproject.org one?
>>
>> External, they exist for workflow reasons right now (e.g. we need to
>> test these builds before submitting external). These bits really
>> should not be under discussion, since we are address the community
>> facing repos in this discussion. In addition we are trying to make
>> more components available externally as well.
>
> By external you mean which? git.yoctoproject.org?

git.yoctoproject.org will host the layers. git.freescale.com will host
the components (linux, u-boot, etc). git.freescale.com will also need
to host a copy of the layers which are hopefully the same as
git.yoctoproject.org for a public facing single place for customers to
pull down the SDK. There is a note about this in the meta-fsl-ppc
README.

> Right but I think the tests will be done by the developer/engineer; in
> case a tree is used for it, this tree could be something like
> linux-next which merges people branches onto a tree and an autobuild
> is triggered ...

Our internal trees are essentially just that.... *-next for each repo.
Given that a full build matrix takes a long time to complete building
and each developer can only do so much so we merge internally and then
post patches. It's just a workflow preference.

>
>>>    I'd like to avoid the huge pile of patches for review and merging
>>> as we've seen done in PPC. This does not scale and makes it harder to
>>> avoid work duplication.
>>
>> Ideally, but there is no guarantees to make here. Priority's and
>> resources are always shifting around.
>
> I understand but what I noticed from PPC pull requests is that they're
> send basing in an old poky/oe-core/meta-oe snapshot and not
> build/tested in current snapshots. This adds extra work for people
> reviewing them as some might even be deprecated in today's upstream
> tree.

Hopefully, all patches posted are only based on master now. But it's
possible that we fall behind and only do active development on an
older release for a period of time.

>
> I don't know the internal workflow but we might try to think a way to
> improve the way those patches are handled so we have more often pull
> requests and do a more incremental work.

I'd like to move as much as possible into the public, however it's
hard to get public facing stuff (e.g. public build machine). But I'm
open for suggestions here. mail + patchworks seems to be ideal as long
as people don't slack off and fall behind.

>>>    Are Freescale engeneers going to work in public repositories?
>>
>> All work should be submitted to external repos right away and we
>> should not be waiting. So internally we are testing against master
>> branches of all external repos.
>
> Fully agree.
>
>>>  * meta-freescale unified
>>>
>>>    Putting another layer where things will be duplicated will make the
>>> documentation and support harder. We'll have users asking questions
>>> which are specific to meta-freescale and does not fit in usual layers
>>> use and it is unavoidable that end users will need to use other layers
>>> to accomplish their needs so I see no reason to differ from regular
>>> use here. In my point of view, the use of a 'repo' (as we done in
>>> fsl-community-bsp) is the way to go as you can provide a well tested
>>> BSP combination, ensure users have a user friendly environment and do
>>> not disrupt the way of working used in usual layers use.
>>>
>>>    I've been using 'repo' layout with customers and it does work quite
>>>  well as it makes trivial for users to use Yocto.
>>
>> repo could work here, or git submodules, or many other ways. I think
>> adopting repo is a good idea since the arm side is already using it in
>> a public way.
>
> Another good point for it is that it is commonly used by people
> working at Android so some people are aready used to it. Regarding git
> submodules I didn't like it when we tried as it is very easy to make
> bad things with it but it does solve same problem.
>
>>>  * branch/tagging policy
>>>
>>>    The maintainence policy we have for the branches are the same as
>>> Yocto and thus the branching and tagging will follow the Yocto
>>> branching and tagging. This is another reason why I think the use of
>>> 'repo' might be good as it allow for tagging of the 'repo' manifest to
>>> make releases.
>>>
>>>  * SCM
>>>
>>>    I use Gerrit internally for customers work and I also think it is a
>>> good addition for internal work however please don't use it for public
>>> layers work. As I said before, people tend to have a huge set of
>>> patches before sending to upstream merge and this makes things harder
>>> for everyone. Public repositories ought to be the ones used for
>>> internal development (except when new SoC or similar is being done).
>>
>> I don't think this will be public. It's sort of an internal bit that
>> got shared. We will keep posting patches to meta-freescale for review
>> and then they will be applied.
>
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Tue, Feb 26, 2013 at 3:44 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Feb 26, 2013 at 6:21 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Tue, Feb 26, 2013 at 2:15 AM, Luo Zhenhua-B19537
>> <B19537@freescale.com> wrote:
>>> Hello Otavio and all,
>>>
>>> The FSL Yocto layers reorg proposal is attached, can you please take a look?
>>> Any comment and suggestion is welcome and appreciated.
>>>
>>
>> 1) Don't cross post to internal and external mailing lists.
>>
>> 2) I still don't really see the point in renaming from meta-fsl-ppc ->
>> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
>> what others think about this. It seems like unneeded changes that will
>> just cause confusion. Why not just put vybird in meta-fsl-arm?
>
> I support this idea and it'd make users' life much easier.
>
>> 3) I think we should delay the creation of some of these layers until
>> we really have packages that are duplicated between two layers (e.g.
>> meta-layerscape can wait until we have a recipe that is needed for
>> both ARM and PPC and is not upstream in another layer)
>
> Personally I think it won't happen often as usually it'll not be a BSP
> package that will fit in this set so it'll end in meta-virtualization
> or meta-networking eventually.

I basically agree with this. Put this in the BSP layer so in this case
meta-fsl-networking.

>
>> 4) I think we need some more info about the "unifed" layer. I don't
>> think it needs to exist yet, but maybe others would like to see it.
>> Personally, I think it can be created automatically much like poky is
>> now.
>
> As I said, I fear it adding more confusing than solving. It might
> making users wonder which layer he/she will use and don't know exactly
> the difference between the merged layer and the individual ones.

I agree here too, unless someone comes up with a really good reason.

-M

>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[Fabio Estevam]

On Tue, Feb 26, 2013 at 6:21 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:

> 1) Don't cross post to internal and external mailing lists.
>
> 2) I still don't really see the point in renaming from meta-fsl-ppc ->
> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
> what others think about this. It seems like unneeded changes that will
> just cause confusion. Why not just put vybird in meta-fsl-arm?

I agree with keeping meta-fsl-arm and adding Vybrid into it.

Re: Please review the proposal of FSL Yocto layers reorg

[Luo Zhenhua-B19537]

> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
> Behalf Of Otavio Salvador
> Sent: Wednesday, February 27, 2013 5:44 AM
> 
> > 2) I still don't really see the point in renaming from meta-fsl-ppc ->
> > meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
> > what others think about this. It seems like unneeded changes that will
> > just cause confusion. Why not just put vybird in meta-fsl-arm?
> 
> I support this idea and it'd make users' life much easier.
[Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets. 
	i.MX guys, any other reason for the renaming?

> > 3) I think we should delay the creation of some of these layers until
> > we really have packages that are duplicated between two layers (e.g.
> > meta-layerscape can wait until we have a recipe that is needed for
> > both ARM and PPC and is not upstream in another layer)
> 
> Personally I think it won't happen often as usually it'll not be a BSP
> package that will fit in this set so it'll end in meta-virtualization or
> meta-networking eventually.
[Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible. 

> > 4) I think we need some more info about the "unifed" layer. I don't
> > think it needs to exist yet, but maybe others would like to see it.
> > Personally, I think it can be created automatically much like poky is
> > now.
> 
> As I said, I fear it adding more confusing than solving. It might making
> users wonder which layer he/she will use and don't know exactly the
> difference between the merged layer and the individual ones.
[Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository. 


Best Regards,

Zhenhua

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Wed, Feb 27, 2013 at 3:57 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, February 27, 2013 5:44 AM
>>
>> > 2) I still don't really see the point in renaming from meta-fsl-ppc ->
>> > meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I wonder
>> > what others think about this. It seems like unneeded changes that will
>> > just cause confusion. Why not just put vybird in meta-fsl-arm?
>>
>> I support this idea and it'd make users' life much easier.
> [Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets.
>         i.MX guys, any other reason for the renaming?

Not necessarially; personally I think users will like to have to worry
about less layers. It even facilitates the reuse of code and make
documentation easier. From my point of view, meta-fsl-arm and
meta-fsl-ppc could be the two BSP layers and others could be add
around (meta-fsl-networking, meta-fsl-multimedia, ...) in
git.freescale.com for extra images and demo recipes.

>> > 3) I think we should delay the creation of some of these layers until
>> > we really have packages that are duplicated between two layers (e.g.
>> > meta-layerscape can wait until we have a recipe that is needed for
>> > both ARM and PPC and is not upstream in another layer)
>>
>> Personally I think it won't happen often as usually it'll not be a BSP
>> package that will fit in this set so it'll end in meta-virtualization or
>> meta-networking eventually.
> [Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible.

Good.

>> > 4) I think we need some more info about the "unifed" layer. I don't
>> > think it needs to exist yet, but maybe others would like to see it.
>> > Personally, I think it can be created automatically much like poky is
>> > now.
>>
>> As I said, I fear it adding more confusing than solving. It might making
>> users wonder which layer he/she will use and don't know exactly the
>> difference between the merged layer and the individual ones.
> [Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository.

But it won't include all needed parts for user so it will only add
confusion. What makes fsl-community-bsp nice is that it does all for
you and gives you a working solution however meta-freescale will give
you a set of layers, only.

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

Re: Please review the proposal of FSL Yocto layers reorg

[Bob Cochran]

>
> The FSL Yocto layers reorg proposal is attached, can you please take a
> look? Any comment and suggestion is welcome and appreciated.
>

Thanks Zhenhua.  I have a few questions and comments about your slides.

*** Slide 2: "Move all FSL specific layers to totally open source, or as 
much as possible"

I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't 
see mention of this in your slides.  This can be found today on your 
public git, but it hasn't been updated in months.

I assume there's lots of kernel activity (as can be witnessed on the 
linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux 
tree is being patched often.  It would be great to be able to see your 
Linux tree patched as issues are being discussed & resolved on yocto & 
ozlabs mail lists.



**** Slide 3: "FSL Layers maintained in git.am.freescale.net, 
gitfrescale.com, and git.yoctoproject.org"

Is your goal to have these layers in sync?  Today, I can find a 
meta-fsl-ppc layer on yoctoproject and at git.freescale.com.  However, 
they are not in sync, and I have no idea why one is patched and one isn't.


**** Slide 4: "Following layers will coexist:"

I'm not sure what you mean.  Do you mean that a layer (e.g., poky) will 
exist separately on different servers?


**** Slide 6: "A branch is created for each FSL SDK release to include 
the scripts to fetch..."

I'm all for this one. Obviously, an SDK release implies a certain level 
of robustness.  I would like to see high quality, reviewed patches 
applied to an SDK branch as necessary so well defined, robust 
incremental releases could be generated between the ~6 month SDK release 
cycle.  The patches would only be bug fixes and not new package or 
recipe versions.


Thanks,

Bob

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Wed, Feb 27, 2013 at 2:08 PM, Bob Cochran <yocto@mindchasers.com> wrote:
>
>>
>> The FSL Yocto layers reorg proposal is attached, can you please take a
>> look? Any comment and suggestion is welcome and appreciated.
>>
>
> Thanks Zhenhua.  I have a few questions and comments about your slides.
>
> *** Slide 2: "Move all FSL specific layers to totally open source, or as
> much as possible"
>
> I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't see
> mention of this in your slides.  This can be found today on your public git,
> but it hasn't been updated in months.
>
> I assume there's lots of kernel activity (as can be witnessed on the
> linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux tree
> is being patched often.  It would be great to be able to see your Linux tree
> patched as issues are being discussed & resolved on yocto & ozlabs mail
> lists.

We work on the upstream tree and also release an SDK kernel tree
that's fully tested. The layers tend to use the latter since it
supports all features. Nothing stopping users from adding a version
using the upstream tree.

>
>
>
> **** Slide 3: "FSL Layers maintained in git.am.freescale.net,
> gitfrescale.com, and git.yoctoproject.org"
>
> Is your goal to have these layers in sync?  Today, I can find a meta-fsl-ppc
> layer on yoctoproject and at git.freescale.com.  However, they are not in
> sync, and I have no idea why one is patched and one isn't.

They are somewhat in sync. The ones on git.freescale.com are still
denzil based for the last SDK release. Ones on git.yoctoproject.org
are newer and include danny and master branches as well.

>
>
> **** Slide 4: "Following layers will coexist:"
>
> I'm not sure what you mean.  Do you mean that a layer (e.g., poky) will
> exist separately on different servers?

I think it just means all these layers will be present in this phase.

>
>
> **** Slide 6: "A branch is created for each FSL SDK release to include the
> scripts to fetch..."
>
> I'm all for this one. Obviously, an SDK release implies a certain level of
> robustness.  I would like to see high quality, reviewed patches applied to
> an SDK branch as necessary so well defined, robust incremental releases
> could be generated between the ~6 month SDK release cycle.  The patches
> would only be bug fixes and not new package or recipe versions.
>
>
> Thanks,
>
> Bob
>
>
>
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Wed, Feb 27, 2013 at 5:57 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Wed, Feb 27, 2013 at 2:08 PM, Bob Cochran <yocto@mindchasers.com> wrote:
>>
>>>
>>> The FSL Yocto layers reorg proposal is attached, can you please take a
>>> look? Any comment and suggestion is welcome and appreciated.
>>>
>>
>> Thanks Zhenhua.  I have a few questions and comments about your slides.
>>
>> *** Slide 2: "Move all FSL specific layers to totally open source, or as
>> much as possible"
>>
>> I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't see
>> mention of this in your slides.  This can be found today on your public git,
>> but it hasn't been updated in months.
>>
>> I assume there's lots of kernel activity (as can be witnessed on the
>> linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux tree
>> is being patched often.  It would be great to be able to see your Linux tree
>> patched as issues are being discussed & resolved on yocto & ozlabs mail
>> lists.
>
> We work on the upstream tree and also release an SDK kernel tree
> that's fully tested. The layers tend to use the latter since it
> supports all features. Nothing stopping users from adding a version
> using the upstream tree.

And from now on, what are the plans?

>> **** Slide 3: "FSL Layers maintained in git.am.freescale.net,
>> gitfrescale.com, and git.yoctoproject.org"
>>
>> Is your goal to have these layers in sync?  Today, I can find a meta-fsl-ppc
>> layer on yoctoproject and at git.freescale.com.  However, they are not in
>> sync, and I have no idea why one is patched and one isn't.
>
> They are somewhat in sync. The ones on git.freescale.com are still
> denzil based for the last SDK release. Ones on git.yoctoproject.org
> are newer and include danny and master branches as well.

And what are the plans regarding the SDK?

>> **** Slide 4: "Following layers will coexist:"
>>
>> I'm not sure what you mean.  Do you mean that a layer (e.g., poky) will
>> exist separately on different servers?
>
> I think it just means all these layers will be present in this phase.
>
>>
>>
>> **** Slide 6: "A branch is created for each FSL SDK release to include the
>> scripts to fetch..."
>>
>> I'm all for this one. Obviously, an SDK release implies a certain level of
>> robustness.  I would like to see high quality, reviewed patches applied to
>> an SDK branch as necessary so well defined, robust incremental releases
>> could be generated between the ~6 month SDK release cycle.  The patches
>> would only be bug fixes and not new package or recipe versions.
>>
>>
>> Thanks,
>>
>> Bob
>>
>>
>>
>>
>>
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale



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

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Wed, Feb 27, 2013 at 3:03 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Wed, Feb 27, 2013 at 5:57 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Wed, Feb 27, 2013 at 2:08 PM, Bob Cochran <yocto@mindchasers.com> wrote:
>>>
>>>>
>>>> The FSL Yocto layers reorg proposal is attached, can you please take a
>>>> look? Any comment and suggestion is welcome and appreciated.
>>>>
>>>
>>> Thanks Zhenhua.  I have a few questions and comments about your slides.
>>>
>>> *** Slide 2: "Move all FSL specific layers to totally open source, or as
>>> much as possible"
>>>
>>> I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't see
>>> mention of this in your slides.  This can be found today on your public git,
>>> but it hasn't been updated in months.
>>>
>>> I assume there's lots of kernel activity (as can be witnessed on the
>>> linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux tree
>>> is being patched often.  It would be great to be able to see your Linux tree
>>> patched as issues are being discussed & resolved on yocto & ozlabs mail
>>> lists.
>>
>> We work on the upstream tree and also release an SDK kernel tree
>> that's fully tested. The layers tend to use the latter since it
>> supports all features. Nothing stopping users from adding a version
>> using the upstream tree.
>
> And from now on, what are the plans?

Same using SDK kernel release, I don't think the kernel team will ever
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)

>
>>> **** Slide 3: "FSL Layers maintained in git.am.freescale.net,
>>> gitfrescale.com, and git.yoctoproject.org"
>>>
>>> Is your goal to have these layers in sync?  Today, I can find a meta-fsl-ppc
>>> layer on yoctoproject and at git.freescale.com.  However, they are not in
>>> sync, and I have no idea why one is patched and one isn't.
>>
>> They are somewhat in sync. The ones on git.freescale.com are still
>> denzil based for the last SDK release. Ones on git.yoctoproject.org
>> are newer and include danny and master branches as well.
>
> And what are the plans regarding the SDK?

These should be much closer to the same going forward (ideally
anyways) if not identically esp. for the layers we control, however we
can't always get all fixes in the oe-core/poky for an SDK release. But
a lot of times we can get them into the branch for that release and
eventually a point release.

-M

Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Luo Zhenhua-B19537]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Hello all,

Thanks a lot for the comments.

I did some update according to the feedback and removed some bits of internal activity. Please review and comment. 


Best Regards,

Zhenhua

[-- Attachment #2: FSL_Yocto_Layers_Reorg_28-Feb.pdf --]
[-- Type: application/pdf, Size: 692197 bytes --]

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Otavio Salvador]

On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
<B19537@freescale.com> wrote:
> Hello all,
>
> Thanks a lot for the comments.
>
> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.

From the update, I think it is much more inline with I believe it'd be
the best way of doing it. Personally I found two things which could be
further discussed:

* meta-fsl-layerscale:

  As Vybrid it could have the BSP part inside meta-fsl-arm and
meta-fsl-ppc; I think the not BSP parts could go to
meta-fsl-networking or similar and keep the BSP part unified. This
would make easier for users and also make it easier for vendors to
make customized BSPs using this as a common base.

* meta-freescale-sdk:

  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?

Regards,

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

Re: Please review the proposal of FSL Yocto layers reorg

[Bob Cochran]

On 02/27/2013 04:07 PM, McClintock Matthew-B29882 wrote:
> On Wed, Feb 27, 2013 at 3:03 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Wed, Feb 27, 2013 at 5:57 PM, McClintock Matthew-B29882
>> <B29882@freescale.com> wrote:
>>> On Wed, Feb 27, 2013 at 2:08 PM, Bob Cochran <yocto@mindchasers.com> wrote:
>>>>
>>>>>
>>>>> The FSL Yocto layers reorg proposal is attached, can you please take a
>>>>> look? Any comment and suggestion is welcome and appreciated.
>>>>>
>>>>
>>>> Thanks Zhenhua.  I have a few questions and comments about your slides.
>>>>
>>>> *** Slide 2: "Move all FSL specific layers to totally open source, or as
>>>> much as possible"
>>>>
>>>> I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't see
>>>> mention of this in your slides.  This can be found today on your public git,
>>>> but it hasn't been updated in months.
>>>>
>>>> I assume there's lots of kernel activity (as can be witnessed on the
>>>> linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux tree
>>>> is being patched often.  It would be great to be able to see your Linux tree
>>>> patched as issues are being discussed & resolved on yocto & ozlabs mail
>>>> lists.
>>>
>>> We work on the upstream tree and also release an SDK kernel tree
>>> that's fully tested. The layers tend to use the latter since it
>>> supports all features. Nothing stopping users from adding a version
>>> using the upstream tree.
>>
>> And from now on, what are the plans?
>
> Same using SDK kernel release, I don't think the kernel team will ever
> 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)
>
>>
>>>> **** Slide 3: "FSL Layers maintained in git.am.freescale.net,
>>>> gitfrescale.com, and git.yoctoproject.org"
>>>>
>>>> Is your goal to have these layers in sync?  Today, I can find a meta-fsl-ppc
>>>> layer on yoctoproject and at git.freescale.com.  However, they are not in
>>>> sync, and I have no idea why one is patched and one isn't.
>>>
>>> They are somewhat in sync.


That's today.  What about next week or next month?  As Zhenhua develops 
the revised Yocto layer strategy, I ask that he clarifies the policy on 
how the same named tree on different servers will be maintained.



The ones on git.freescale.com are still
>>> denzil based for the last SDK release. Ones on git.yoctoproject.org
>>> are newer and include danny and master branches as well.
>>
>> And what are the plans regarding the SDK?


Can we get a statement in the Yocto layers reorg doc on how each SDK 
branch will be maintained between SDK releases?  As a developer working 
to get products out the door, will I view the patched SDK branch 
(between releases) as a bug fixed SDK or as an experimental branch for 
the next SDK release?


>
> These should be much closer to the same going forward (ideally
> anyways) if not identically esp. for the layers we control, however we
> can't always get all fixes in the oe-core/poky for an SDK release. But
> a lot of times we can get them into the branch for that release and
> eventually a point release.
>
> -M
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 8:32 AM, Bob Cochran <yocto@mindchasers.com> wrote:
> On 02/27/2013 04:07 PM, McClintock Matthew-B29882 wrote:
>>
>> On Wed, Feb 27, 2013 at 3:03 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>>
>>> On Wed, Feb 27, 2013 at 5:57 PM, McClintock Matthew-B29882
>>> <B29882@freescale.com> wrote:
>>>>
>>>> On Wed, Feb 27, 2013 at 2:08 PM, Bob Cochran <yocto@mindchasers.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> The FSL Yocto layers reorg proposal is attached, can you please take a
>>>>>> look? Any comment and suggestion is welcome and appreciated.
>>>>>>
>>>>>
>>>>> Thanks Zhenhua.  I have a few questions and comments about your slides.
>>>>>
>>>>> *** Slide 2: "Move all FSL specific layers to totally open source, or
>>>>> as
>>>>> much as possible"
>>>>>
>>>>> I'm all for this.  Will this include your PowerPC Linux Tree?  I didn't
>>>>> see
>>>>> mention of this in your slides.  This can be found today on your public
>>>>> git,
>>>>> but it hasn't been updated in months.
>>>>>
>>>>> I assume there's lots of kernel activity (as can be witnessed on the
>>>>> linuxppc-dev@lists.ozlabs.org list), so I'm assuming an internal Linux
>>>>> tree
>>>>> is being patched often.  It would be great to be able to see your Linux
>>>>> tree
>>>>> patched as issues are being discussed & resolved on yocto & ozlabs mail
>>>>> lists.
>>>>
>>>>
>>>> We work on the upstream tree and also release an SDK kernel tree
>>>> that's fully tested. The layers tend to use the latter since it
>>>> supports all features. Nothing stopping users from adding a version
>>>> using the upstream tree.
>>>
>>>
>>> And from now on, what are the plans?
>>
>>
>> Same using SDK kernel release, I don't think the kernel team will ever
>> 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)
>>
>>>
>>>>> **** Slide 3: "FSL Layers maintained in git.am.freescale.net,
>>>>> gitfrescale.com, and git.yoctoproject.org"
>>>>>
>>>>> Is your goal to have these layers in sync?  Today, I can find a
>>>>> meta-fsl-ppc
>>>>> layer on yoctoproject and at git.freescale.com.  However, they are not
>>>>> in
>>>>> sync, and I have no idea why one is patched and one isn't.
>>>>
>>>>
>>>> They are somewhat in sync.
>
>
>
> That's today.  What about next week or next month?  As Zhenhua develops the
> revised Yocto layer strategy, I ask that he clarifies the policy on how the
> same named tree on different servers will be maintained.
>
>
>
>
> The ones on git.freescale.com are still
>>>>
>>>> denzil based for the last SDK release. Ones on git.yoctoproject.org
>>>> are newer and include danny and master branches as well.
>>>
>>>
>>> And what are the plans regarding the SDK?
>
>
>
> Can we get a statement in the Yocto layers reorg doc on how each SDK branch
> will be maintained between SDK releases?  As a developer working to get
> products out the door, will I view the patched SDK branch (between releases)
> as a bug fixed SDK or as an experimental branch for the next SDK release?

I understand the sentiment but I don't think we can guarantee anything
here. This is all done for free after all. I understand that's not a
great answer but there are always limited resources spread around.

Upstream / public branches will try to work with all Yocto releases,
while SDK releases could contain a lot of hacks to more things
working, or pre-release things out there door.

-M

Re: Please review the proposal of FSL Yocto layers reorg

[Eric Bénard]

Hi Matthew,

Le Thu, 28 Feb 2013 15:39:49 +0000,
McClintock Matthew-B29882 <B29882@freescale.com> a écrit :

> On Thu, Feb 28, 2013 at 8:32 AM, Bob Cochran <yocto@mindchasers.com> wrote:
> > Can we get a statement in the Yocto layers reorg doc on how each SDK branch
> > will be maintained between SDK releases?  As a developer working to get
> > products out the door, will I view the patched SDK branch (between releases)
> > as a bug fixed SDK or as an experimental branch for the next SDK release?
> 
> I understand the sentiment but I don't think we can guarantee anything
> here. This is all done for free after all. I understand that's not a
> great answer but there are always limited resources spread around.
> 
that may be done for free but don't you think that providing up to date
software support for its components is a good added value for a company
which makes money by selling components like Freescale ?

You have a great interest in having as much people as possible using
your components to get money from them.
You can make the life of developers easier by having master _and_
stable branches up to date (with a big warning in the ReadMe concerning
the fact peoples using the git branches get _community_ support and not
official support you may provide on your official release which can be
downloaded from your website).

So you can make happy both peoples who need stability to release their
products asap (and may benefit from the latest fixes not yet released
in the official release) and peoples who want to test the bleeding edge
software for more long term projects (and also happy users from the
community which are also contributing for free).

So in the end you give a few for free but in the end you save a lot :
- by getting free feedback from many peoples who can use you up to
  date branches (and that's on a community mailing list so you don't
  have to answer to every problems peoples may ask and can redirect
  them to their Freescale/distributor FAE), 
- by getting free fixes from bleeding edge (and stable branches) users,
- by having community peoples supporting themselves through the mailing
  lists.

You are then using and producing free software in a very positive
way and are in a win win relation with the community and your customers'
developers who can subscribe to the mailing list to joing the community.

Best regards,
Eric

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 10:06 AM, Eric Bénard <eric@eukrea.com> wrote:
> Hi Matthew,
>
> Le Thu, 28 Feb 2013 15:39:49 +0000,
> McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
>
>> On Thu, Feb 28, 2013 at 8:32 AM, Bob Cochran <yocto@mindchasers.com> wrote:
>> > Can we get a statement in the Yocto layers reorg doc on how each SDK branch
>> > will be maintained between SDK releases?  As a developer working to get
>> > products out the door, will I view the patched SDK branch (between releases)
>> > as a bug fixed SDK or as an experimental branch for the next SDK release?
>>
>> I understand the sentiment but I don't think we can guarantee anything
>> here. This is all done for free after all. I understand that's not a
>> great answer but there are always limited resources spread around.
>>
> that may be done for free but don't you think that providing up to date
> software support for its components is a good added value for a company
> which makes money by selling components like Freescale ?

Which is why we are here doing what we do...

> You have a great interest in having as much people as possible using
> your components to get money from them.
> You can make the life of developers easier by having master _and_
> stable branches up to date (with a big warning in the ReadMe concerning
> the fact peoples using the git branches get _community_ support and not
> official support you may provide on your official release which can be
> downloaded from your website).

Which is pretty much what we do...

> So you can make happy both peoples who need stability to release their
> products asap (and may benefit from the latest fixes not yet released
> in the official release) and peoples who want to test the bleeding edge
> software for more long term projects (and also happy users from the
> community which are also contributing for free).

Which is what the SDK is for and the community stuff is for...

> So in the end you give a few for free but in the end you save a lot :
> - by getting free feedback from many peoples who can use you up to
>   date branches (and that's on a community mailing list so you don't
>   have to answer to every problems peoples may ask and can redirect
>   them to their Freescale/distributor FAE),

I agree.

> - by getting free fixes from bleeding edge (and stable branches) users,
> - by having community peoples supporting themselves through the mailing
>   lists.

I agree.

> You are then using and producing free software in a very positive
> way and are in a win win relation with the community and your customers'
> developers who can subscribe to the mailing list to joing the community.

I agree.

I think you misinterpreted the intent of my statement, the goal is to
provide the best support we can for the open source versions and get
feedback as well. However, specifically stating what will be done for
each release, branch, layer, etc is not something that is a
deliverable on the open source end and I don't see it happening soon.
That being said, there is no malicious intent and supporting upstream
and making it work as well as possible is the ultimate goal so our SDK
release requires less effort and work.

-M

Re: Please review the proposal of FSL Yocto layers reorg

[Eric Bénard]

Le Thu, 28 Feb 2013 16:52:02 +0000,
McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
> I think you misinterpreted the intent of my statement, the goal is to
> provide the best support we can for the open source versions and get
> feedback as well. However, specifically stating what will be done for
> each release, branch, layer, etc is not something that is a
> deliverable on the open source end and I don't see it happening soon.
> That being said, there is no malicious intent and supporting upstream
> and making it work as well as possible is the ultimate goal so our SDK
> release requires less effort and work.
> 
I may have misinterpreted your statement but it seems you make a
difference between the open source version and the SDK release : isn't
that roughly the same thing when we talk of meta-fsl-* where the SDK
release can be seen as a snapshots of the opensource stable branch at
the date of the release ? If not what are the differences ?

Also, do you plan to sync the public accessible git tree only when you
do a release or will they get the patches in "realtime" ?

Eric

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 11:18 AM, Eric Bénard <eric@eukrea.com> wrote:
> Le Thu, 28 Feb 2013 16:52:02 +0000,
> McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
>> I think you misinterpreted the intent of my statement, the goal is to
>> provide the best support we can for the open source versions and get
>> feedback as well. However, specifically stating what will be done for
>> each release, branch, layer, etc is not something that is a
>> deliverable on the open source end and I don't see it happening soon.
>> That being said, there is no malicious intent and supporting upstream
>> and making it work as well as possible is the ultimate goal so our SDK
>> release requires less effort and work.
>>
> I may have misinterpreted your statement but it seems you make a
> difference between the open source version and the SDK release : isn't
> that roughly the same thing when we talk of meta-fsl-* where the SDK
> release can be seen as a snapshots of the opensource stable branch at
> the date of the release ? If not what are the differences ?

They *should* be the same. But for SDK releases sometimes we skip
entire Yocto releases (e.g. danny). SDK versions *may* contain
slightly different versions. This comes into play more with oe-core
where we don't have official control and we need to include a specific
fix for the SDK. Layers themselves tend to have less reason to deviate
from the upstream versions since we control both sides so they
*should* be the same.

> Also, do you plan to sync the public accessible git tree only when you
> do a release or will they get the patches in "realtime" ?

These should go in real time esp. if we are working on the current
release (e.g. master branch). Right now we are still using denzil
until the May release which will be based on what is now master.

-M

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 6:10 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
> <B19537@freescale.com> wrote:
>> Hello all,
>>
>> Thanks a lot for the comments.
>>
>> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>
> From the update, I think it is much more inline with I believe it'd be
> the best way of doing it. Personally I found two things which could be
> further discussed:
>
> * meta-fsl-layerscale:
>
>   As Vybrid it could have the BSP part inside meta-fsl-arm and
> meta-fsl-ppc; I think the not BSP parts could go to
> meta-fsl-networking or similar and keep the BSP part unified. This
> would make easier for users and also make it easier for vendors to
> make customized BSPs using this as a common base.

I think layerscape and vybrid recipes should go in their own
SDK/distro layers (what does not belong in meta-fsl-{ppc,arm})

> * meta-freescale-sdk:
>
>   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.

-M

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Otavio Salvador]

On Thu, Feb 28, 2013 at 4:17 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Thu, Feb 28, 2013 at 6:10 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
>> <B19537@freescale.com> wrote:
>>> Hello all,
>>>
>>> Thanks a lot for the comments.
>>>
>>> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>>
>> From the update, I think it is much more inline with I believe it'd be
>> the best way of doing it. Personally I found two things which could be
>> further discussed:
>>
>> * meta-fsl-layerscale:
>>
>>   As Vybrid it could have the BSP part inside meta-fsl-arm and
>> meta-fsl-ppc; I think the not BSP parts could go to
>> meta-fsl-networking or similar and keep the BSP part unified. This
>> would make easier for users and also make it easier for vendors to
>> make customized BSPs using this as a common base.
>
> I think layerscape and vybrid recipes should go in their own
> SDK/distro layers (what does not belong in meta-fsl-{ppc,arm})

From my point of view, BSP could go to meta-fsl-{ppc,arm} and
networking/multimedia go to the respective layers.

>> * meta-freescale-sdk:
>>
>>   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.

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

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 1:20 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Thu, Feb 28, 2013 at 4:17 PM, McClintock Matthew-B29882
> <B29882@freescale.com> wrote:
>> On Thu, Feb 28, 2013 at 6:10 AM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
>>> <B19537@freescale.com> wrote:
>>>> Hello all,
>>>>
>>>> Thanks a lot for the comments.
>>>>
>>>> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>>>
>>> From the update, I think it is much more inline with I believe it'd be
>>> the best way of doing it. Personally I found two things which could be
>>> further discussed:
>>>
>>> * meta-fsl-layerscale:
>>>
>>>   As Vybrid it could have the BSP part inside meta-fsl-arm and
>>> meta-fsl-ppc; I think the not BSP parts could go to
>>> meta-fsl-networking or similar and keep the BSP part unified. This
>>> would make easier for users and also make it easier for vendors to
>>> make customized BSPs using this as a common base.
>>
>> I think layerscape and vybrid recipes should go in their own
>> SDK/distro layers (what does not belong in meta-fsl-{ppc,arm})
>
> From my point of view, BSP could go to meta-fsl-{ppc,arm} and
> networking/multimedia go to the respective layers.

Right, board support should in in the meta-fsl-{ppc,arm} and extra
recipes/support in the networking/multimedia layers

>>> * meta-freescale-sdk:
>>>
>>>   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?

-M

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Otavio Salvador]

On Thu, Feb 28, 2013 at 4:37 PM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Thu, Feb 28, 2013 at 1:20 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Thu, Feb 28, 2013 at 4:17 PM, McClintock Matthew-B29882
>> <B29882@freescale.com> wrote:
>>> On Thu, Feb 28, 2013 at 6:10 AM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>>>> On Thu, Feb 28, 2013 at 3:16 AM, Luo Zhenhua-B19537
>>>> <B19537@freescale.com> wrote:
>>>>> Hello all,
>>>>>
>>>>> Thanks a lot for the comments.
>>>>>
>>>>> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>>>>
>>>> From the update, I think it is much more inline with I believe it'd be
>>>> the best way of doing it. Personally I found two things which could be
>>>> further discussed:
>>>>
>>>> * meta-fsl-layerscale:
>>>>
>>>>   As Vybrid it could have the BSP part inside meta-fsl-arm and
>>>> meta-fsl-ppc; I think the not BSP parts could go to
>>>> meta-fsl-networking or similar and keep the BSP part unified. This
>>>> would make easier for users and also make it easier for vendors to
>>>> make customized BSPs using this as a common base.
>>>
>>> I think layerscape and vybrid recipes should go in their own
>>> SDK/distro layers (what does not belong in meta-fsl-{ppc,arm})
>>
>> From my point of view, BSP could go to meta-fsl-{ppc,arm} and
>> networking/multimedia go to the respective layers.
>
> Right, board support should in in the meta-fsl-{ppc,arm} and extra
> recipes/support in the networking/multimedia layers
>
>>>> * meta-freescale-sdk:
>>>>
>>>>   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.

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

Re: Please review the proposal of FSL Yocto layers reorg

[Eric Bénard]

Le Thu, 28 Feb 2013 18:59:41 +0000,
McClintock Matthew-B29882 <B29882@freescale.com> a écrit :

> On Thu, Feb 28, 2013 at 11:18 AM, Eric Bénard <eric@eukrea.com> wrote:
> > Le Thu, 28 Feb 2013 16:52:02 +0000,
> > McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
> >> I think you misinterpreted the intent of my statement, the goal is to
> >> provide the best support we can for the open source versions and get
> >> feedback as well. However, specifically stating what will be done for
> >> each release, branch, layer, etc is not something that is a
> >> deliverable on the open source end and I don't see it happening soon.
> >> That being said, there is no malicious intent and supporting upstream
> >> and making it work as well as possible is the ultimate goal so our SDK
> >> release requires less effort and work.
> >>
> > I may have misinterpreted your statement but it seems you make a
> > difference between the open source version and the SDK release : isn't
> > that roughly the same thing when we talk of meta-fsl-* where the SDK
> > release can be seen as a snapshots of the opensource stable branch at
> > the date of the release ? If not what are the differences ?
> 
> They *should* be the same. But for SDK releases sometimes we skip
> entire Yocto releases (e.g. danny). SDK versions *may* contain
> slightly different versions. This comes into play more with oe-core
> where we don't have official control and we need to include a specific
> fix for the SDK. Layers themselves tend to have less reason to deviate
> from the upstream versions since we control both sides so they
> *should* be the same.
> 
> > Also, do you plan to sync the public accessible git tree only when you
> > do a release or will they get the patches in "realtime" ?
> 
> These should go in real time esp. if we are working on the current
> release (e.g. master branch). Right now we are still using denzil
> until the May release which will be based on what is now master.
> 
understood, thanks for the details.

One last thing while at it : last year, Linaro's FSL team told me they
were about to release an updated kernel for i.MX53 (with updated GPU
closed source libraries & drivers as they had sources for that under
NDA - the userspace binaries are packed into an hwpack named something
like hwpack_linaro-lt-mx5_YYYYMMDD_armel_supported.tar.gz ).
In the end that was never made public but from what I understood they
delivered the sources to Freescale : are there any plan to release
these versions (even if that's not officialy supported by Freescale SDK
and marked as experimental) to meta-fsl-arm so that we can update i.MX53
based designs to more recent kernel than 2.6.35 and still use the GPU ?

Thanks,
Eric

Re: Please review the proposal of FSL Yocto layers reorg

[McClintock Matthew-B29882]

On Thu, Feb 28, 2013 at 4:21 PM, Eric Bénard <eric@eukrea.com> wrote:
> Le Thu, 28 Feb 2013 18:59:41 +0000,
> McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
>
>> On Thu, Feb 28, 2013 at 11:18 AM, Eric Bénard <eric@eukrea.com> wrote:
>> > Le Thu, 28 Feb 2013 16:52:02 +0000,
>> > McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
>> >> I think you misinterpreted the intent of my statement, the goal is to
>> >> provide the best support we can for the open source versions and get
>> >> feedback as well. However, specifically stating what will be done for
>> >> each release, branch, layer, etc is not something that is a
>> >> deliverable on the open source end and I don't see it happening soon.
>> >> That being said, there is no malicious intent and supporting upstream
>> >> and making it work as well as possible is the ultimate goal so our SDK
>> >> release requires less effort and work.
>> >>
>> > I may have misinterpreted your statement but it seems you make a
>> > difference between the open source version and the SDK release : isn't
>> > that roughly the same thing when we talk of meta-fsl-* where the SDK
>> > release can be seen as a snapshots of the opensource stable branch at
>> > the date of the release ? If not what are the differences ?
>>
>> They *should* be the same. But for SDK releases sometimes we skip
>> entire Yocto releases (e.g. danny). SDK versions *may* contain
>> slightly different versions. This comes into play more with oe-core
>> where we don't have official control and we need to include a specific
>> fix for the SDK. Layers themselves tend to have less reason to deviate
>> from the upstream versions since we control both sides so they
>> *should* be the same.
>>
>> > Also, do you plan to sync the public accessible git tree only when you
>> > do a release or will they get the patches in "realtime" ?
>>
>> These should go in real time esp. if we are working on the current
>> release (e.g. master branch). Right now we are still using denzil
>> until the May release which will be based on what is now master.
>>
> understood, thanks for the details.
>
> One last thing while at it : last year, Linaro's FSL team told me they
> were about to release an updated kernel for i.MX53 (with updated GPU
> closed source libraries & drivers as they had sources for that under
> NDA - the userspace binaries are packed into an hwpack named something
> like hwpack_linaro-lt-mx5_YYYYMMDD_armel_supported.tar.gz ).
> In the end that was never made public but from what I understood they
> delivered the sources to Freescale : are there any plan to release
> these versions (even if that's not officialy supported by Freescale SDK
> and marked as experimental) to meta-fsl-arm so that we can update i.MX53
> based designs to more recent kernel than 2.6.35 and still use the GPU ?

Most of my comments reflect on the ppc / networking side of our
organization. So I can't comment on the ARM / Linaro bits.

-M

Re: Please review the proposal of FSL Yocto layers reorg

[Bob Cochran]

On 02/28/2013 01:59 PM, McClintock Matthew-B29882 wrote:
> On Thu, Feb 28, 2013 at 11:18 AM, Eric Bénard <eric@eukrea.com> wrote:
>> Le Thu, 28 Feb 2013 16:52:02 +0000,
>> McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
>>> I think you misinterpreted the intent of my statement, the goal is to
>>> provide the best support we can for the open source versions and get
>>> feedback as well. However, specifically stating what will be done for
>>> each release, branch, layer, etc is not something that is a
>>> deliverable on the open source end and I don't see it happening soon.
>>> That being said, there is no malicious intent and supporting upstream
>>> and making it work as well as possible is the ultimate goal so our SDK
>>> release requires less effort and work.
>>>
>> I may have misinterpreted your statement but it seems you make a
>> difference between the open source version and the SDK release : isn't
>> that roughly the same thing when we talk of meta-fsl-* where the SDK
>> release can be seen as a snapshots of the opensource stable branch at
>> the date of the release ? If not what are the differences ?
>
> They *should* be the same. But for SDK releases sometimes we skip
> entire Yocto releases (e.g. danny). SDK versions *may* contain
> slightly different versions. This comes into play more with oe-core
> where we don't have official control and we need to include a specific
> fix for the SDK. Layers themselves tend to have less reason to deviate
> from the upstream versions since we control both sides so they
> *should* be the same.


Thanks Matthew. It's great that you are explaining things to us, but all 
this information will become stale in a matter of weeks or even days.  I 
believe we need Zhenhua's layers document to describe what we have been 
discussing regarding policies on how the SDK branches will be 
maintained, where to pull the latest stable SDK patches from the various 
servers, and how the same named trees are managed on the different servers.

If nothing can be promised, then at least state it in the document 
rather than gloss over it.

Also, I hope the layers organization document will be posted on an FSL 
site and become maintained documentation or perhaps a Wiki.


>
>> Also, do you plan to sync the public accessible git tree only when you
>> do a release or will they get the patches in "realtime" ?
>
> These should go in real time esp. if we are working on the current
> release (e.g. master branch). Right now we are still using denzil
> until the May release which will be based on what is now master.
>
> -M
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: Please review the proposal of FSL Yocto layers reorg

[Luo Zhenhua-B19537]

Hello all,

Thanks a lot for the feedback.

I will incorporate those information into the FSL Yocto reorg documentation. 


Best Regards,

Zhenhua


> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> Sent: Friday, March 01, 2013 7:30 AM
> To: McClintock Matthew-B29882
> Cc: meta-freescale@yoctoproject.org; Otavio Salvador;
> yocto@linux.freescale.net
> Subject: Re: [meta-freescale] Please review the proposal of FSL Yocto
> layers reorg
> 
> On 02/28/2013 01:59 PM, McClintock Matthew-B29882 wrote:
> > On Thu, Feb 28, 2013 at 11:18 AM, Eric Bénard <eric@eukrea.com> wrote:
> >> Le Thu, 28 Feb 2013 16:52:02 +0000,
> >> McClintock Matthew-B29882 <B29882@freescale.com> a écrit :
> >>> I think you misinterpreted the intent of my statement, the goal is
> >>> to provide the best support we can for the open source versions and
> >>> get feedback as well. However, specifically stating what will be
> >>> done for each release, branch, layer, etc is not something that is a
> >>> deliverable on the open source end and I don't see it happening soon.
> >>> That being said, there is no malicious intent and supporting
> >>> upstream and making it work as well as possible is the ultimate goal
> >>> so our SDK release requires less effort and work.
> >>>
> >> I may have misinterpreted your statement but it seems you make a
> >> difference between the open source version and the SDK release :
> >> isn't that roughly the same thing when we talk of meta-fsl-* where
> >> the SDK release can be seen as a snapshots of the opensource stable
> >> branch at the date of the release ? If not what are the differences ?
> >
> > They *should* be the same. But for SDK releases sometimes we skip
> > entire Yocto releases (e.g. danny). SDK versions *may* contain
> > slightly different versions. This comes into play more with oe-core
> > where we don't have official control and we need to include a specific
> > fix for the SDK. Layers themselves tend to have less reason to deviate
> > from the upstream versions since we control both sides so they
> > *should* be the same.
> 
> 
> Thanks Matthew. It's great that you are explaining things to us, but all
> this information will become stale in a matter of weeks or even days.  I
> believe we need Zhenhua's layers document to describe what we have been
> discussing regarding policies on how the SDK branches will be maintained,
> where to pull the latest stable SDK patches from the various servers, and
> how the same named trees are managed on the different servers.
> 
> If nothing can be promised, then at least state it in the document rather
> than gloss over it.
> 
> Also, I hope the layers organization document will be posted on an FSL
> site and become maintained documentation or perhaps a Wiki.
> 
> 
> >
> >> Also, do you plan to sync the public accessible git tree only when you
> >> do a release or will they get the patches in "realtime" ?
> >
> > These should go in real time esp. if we are working on the current
> > release (e.g. master branch). Right now we are still using denzil
> > until the May release which will be based on what is now master.
> >
> > -M
> > _______________________________________________
> > meta-freescale mailing list
> > meta-freescale@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-freescale
> >
> 
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Luo Zhenhua-B19537]

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@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

Re: Please review the proposal of FSL Yocto layers reorg

[Wang Larry-B38019]

About meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid, the reason we prefer the second one is i.MX and Vybrid are so different.  They have different IP blocks, different device drivers in kernel, different interface libs in user space, different SW development/release schedules, different customers.  For that sense, this "ARM" is NOT that "ARM", just like i.MX ARM is not OMAP ARM.  Separating them is more flexible for us, and less confusion for our customers.

Thanks!
Larry 

-----Original Message-----
From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
Sent: Wednesday, February 27, 2013 6:09 AM
To: Luo Zhenhua-B19537
Cc: McClintock Matthew-B29882; Li Yi i.MX-R80015; Mahadevan Mahesh-R9AADQ; Weng White-B18292; Angolini Daiane-B19406; Wang Larry-B38019; Liu Ting-B28495; meta-freescale@yoctoproject.org; Schmitt Richard-B43082; Trefny Thomas-RAT188
Subject: Re: Please review the proposal of FSL Yocto layers reorg

On Wed, Feb 27, 2013 at 3:57 AM, Luo Zhenhua-B19537 <B19537@freescale.com> wrote:
>> -----Original Message-----
>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On 
>> Behalf Of Otavio Salvador
>> Sent: Wednesday, February 27, 2013 5:44 AM
>>
>> > 2) I still don't really see the point in renaming from meta-fsl-ppc 
>> > -> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I 
>> > wonder what others think about this. It seems like unneeded changes 
>> > that will just cause confusion. Why not just put vybird in meta-fsl-arm?
>>
>> I support this idea and it'd make users' life much easier.
> [Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets.
>         i.MX guys, any other reason for the renaming?

Not necessarially; personally I think users will like to have to worry about less layers. It even facilitates the reuse of code and make documentation easier. From my point of view, meta-fsl-arm and meta-fsl-ppc could be the two BSP layers and others could be add around (meta-fsl-networking, meta-fsl-multimedia, ...) in git.freescale.com for extra images and demo recipes.

>> > 3) I think we should delay the creation of some of these layers 
>> > until we really have packages that are duplicated between two layers (e.g.
>> > meta-layerscape can wait until we have a recipe that is needed for 
>> > both ARM and PPC and is not upstream in another layer)
>>
>> Personally I think it won't happen often as usually it'll not be a 
>> BSP package that will fit in this set so it'll end in 
>> meta-virtualization or meta-networking eventually.
> [Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible.

Good.

>> > 4) I think we need some more info about the "unifed" layer. I don't 
>> > think it needs to exist yet, but maybe others would like to see it.
>> > Personally, I think it can be created automatically much like poky 
>> > is now.
>>
>> As I said, I fear it adding more confusing than solving. It might 
>> making users wonder which layer he/she will use and don't know 
>> exactly the difference between the merged layer and the individual ones.
> [Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository.

But it won't include all needed parts for user so it will only add confusion. What makes fsl-community-bsp nice is that it does all for you and gives you a working solution however meta-freescale will give you a set of layers, only.

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

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Wang Larry-B38019]

Sorry for responding late for the previous version.  We still need consider the concerns we have about meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid.  Freescale can make more ARM based processors.  It will be hard to put all of them under one umbrella.

Thanks!
Larry

-----Original Message-----
From: Luo Zhenhua-B19537 
Sent: Thursday, February 28, 2013 12:17 AM
To: Otavio Salvador; Bob Cochran; McClintock Matthew-B29882
Cc: Li Yi i.MX-R80015; Mahadevan Mahesh-R9AADQ; Weng White-B18292; Angolini Daiane-B19406; Wang Larry-B38019; Liu Ting-B28495; Schmitt Richard-B43082; Trefny Thomas-RAT188; meta-freescale@yoctoproject.org
Subject: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

Hello all,

Thanks a lot for the comments.

I did some update according to the feedback and removed some bits of internal activity. Please review and comment. 


Best Regards,

Zhenhua

Re: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb

[Matthew McClintock]

On Fri, Mar 1, 2013 at 9:38 AM, Wang Larry-B38019 <B38019@freescale.com> wrote:
> Sorry for responding late for the previous version.  We still need consider the concerns we have about meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid.  Freescale can make more ARM based processors.  It will be hard to put all of them under one umbrella.

Core board support under one layer is not that hard. It should only be
adding a machine file, and maybe a new kernel / u-boot recipe (or
maybe just pointing at a different SHA/SRC_URI).

Most other stuff will live in a vybrid layer that adds all the
ancillary support recipes.

-M

>
> Thanks!
> Larry
>
> -----Original Message-----
> From: Luo Zhenhua-B19537
> Sent: Thursday, February 28, 2013 12:17 AM
> To: Otavio Salvador; Bob Cochran; McClintock Matthew-B29882
> Cc: Li Yi i.MX-R80015; Mahadevan Mahesh-R9AADQ; Weng White-B18292; Angolini Daiane-B19406; Wang Larry-B38019; Liu Ting-B28495; Schmitt Richard-B43082; Trefny Thomas-RAT188; meta-freescale@yoctoproject.org
> Subject: Please review the proposal of FSL Yocto layers reorg - updated version on 28-Feb
>
> Hello all,
>
> Thanks a lot for the comments.
>
> I did some update according to the feedback and removed some bits of internal activity. Please review and comment.
>
>
> Best Regards,
>
> Zhenhua
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[Matthew McClintock]

On Fri, Mar 1, 2013 at 9:30 AM, Wang Larry-B38019 <B38019@freescale.com> wrote:
> About meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid, the reason we prefer the second one is i.MX and Vybrid are so different.  They have different IP blocks, different device drivers in kernel, different interface libs in user space, different SW development/release schedules, different customers.  For that sense, this "ARM" is NOT that "ARM", just like i.MX ARM is not OMAP ARM.  Separating them is more flexible for us, and less confusion for our customers.

Ok, but you want an entirely separate layer what will live in the core
support layer? A linux/u-boot recipe for the machine? That's not that
hard to keep in sync.

If we do add another layer, I'd prefer NOT to rename meta-fsl-arm and
just add the new one by itself. However, I don't think it's really
needed.

-M

>
> Thanks!
> Larry
>
> -----Original Message-----
> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On Behalf Of Otavio Salvador
> Sent: Wednesday, February 27, 2013 6:09 AM
> To: Luo Zhenhua-B19537
> Cc: McClintock Matthew-B29882; Li Yi i.MX-R80015; Mahadevan Mahesh-R9AADQ; Weng White-B18292; Angolini Daiane-B19406; Wang Larry-B38019; Liu Ting-B28495; meta-freescale@yoctoproject.org; Schmitt Richard-B43082; Trefny Thomas-RAT188
> Subject: Re: Please review the proposal of FSL Yocto layers reorg
>
> On Wed, Feb 27, 2013 at 3:57 AM, Luo Zhenhua-B19537 <B19537@freescale.com> wrote:
>>> -----Original Message-----
>>> From: otavio.salvador@gmail.com [mailto:otavio.salvador@gmail.com] On
>>> Behalf Of Otavio Salvador
>>> Sent: Wednesday, February 27, 2013 5:44 AM
>>>
>>> > 2) I still don't really see the point in renaming from meta-fsl-ppc
>>> > -> meta-fsl-qoriq as well as meta-fsl-arm to meta-fsl-imx. But, I
>>> > wonder what others think about this. It seems like unneeded changes
>>> > that will just cause confusion. Why not just put vybird in meta-fsl-arm?
>>>
>>> I support this idea and it'd make users' life much easier.
>> [Luo Zhenhua-B19537] One reason is, if meta-fsl-arm is used, the i.MX targets and Layerscape arm targets are maintained in the same layer, this might confuse users, E.g. LS arm machines are visible to users of i.MX multimedia SDK. Same for PPC targets.
>>         i.MX guys, any other reason for the renaming?
>
> Not necessarially; personally I think users will like to have to worry about less layers. It even facilitates the reuse of code and make documentation easier. From my point of view, meta-fsl-arm and meta-fsl-ppc could be the two BSP layers and others could be add around (meta-fsl-networking, meta-fsl-multimedia, ...) in git.freescale.com for extra images and demo recipes.
>
>>> > 3) I think we should delay the creation of some of these layers
>>> > until we really have packages that are duplicated between two layers (e.g.
>>> > meta-layerscape can wait until we have a recipe that is needed for
>>> > both ARM and PPC and is not upstream in another layer)
>>>
>>> Personally I think it won't happen often as usually it'll not be a
>>> BSP package that will fit in this set so it'll end in
>>> meta-virtualization or meta-networking eventually.
>> [Luo Zhenhua-B19537] I agree to delay the creation of some layers till they are necessary. We should upstream those shared packages into oe-core/meta-oe/meta-virtualization/... upstream layers as much as possible.
>
> Good.
>
>>> > 4) I think we need some more info about the "unifed" layer. I don't
>>> > think it needs to exist yet, but maybe others would like to see it.
>>> > Personally, I think it can be created automatically much like poky
>>> > is now.
>>>
>>> As I said, I fear it adding more confusing than solving. It might
>>> making users wonder which layer he/she will use and don't know
>>> exactly the difference between the merged layer and the individual ones.
>> [Luo Zhenhua-B19537] there may be some confusion, meta-freescale is similar as https://github.com/Freescale/fsl-community-bsp-platform, it can make it easy for users to download the required layers of right version for a specific FSL SDK. This layer is SDK specific and only maintained in Freescale git repository.
>
> But it won't include all needed parts for user so it will only add confusion. What makes fsl-community-bsp nice is that it does all for you and gives you a working solution however meta-freescale will give you a set of layers, only.
>
> --
> Otavio Salvador                             O.S. Systems
> E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
>
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Please review the proposal of FSL Yocto layers reorg

[Otavio Salvador]

On Fri, Mar 1, 2013 at 12:30 PM, Wang Larry-B38019 <B38019@freescale.com> wrote:
> About meta-fsl-arm vs meta-fsl-imx/meta-fsl-vybrid, the reason we prefer the second one is i.MX and Vybrid are so different.  They have different IP blocks, different device drivers in kernel, different interface libs in user space, different SW development/release schedules, different customers.  For that sense, this "ARM" is NOT that "ARM", just like i.MX ARM is not OMAP ARM.  Separating them is more flexible for us, and less confusion for our customers.

I understand i.MX and Vybrid is different however this is not uncommon
in different layers. Texas Instruments does exactly this and have
different OMAP and SoC versions in same meta-ti layer so it is quite
easy to user to know where to look at when looking for a SoC support.
Intel also does the same supporting Atom (< D2xxx and newer) in same
BSP. We also does this supporting i.MXS, i.MX5 and i.MX6 in same BSP
and all those are quite different from BSP point of view.

Technically I see no reason why to split the layer in several
sub-layers and it is more confusing for customers in my point of view
as someone looking for a SoC support will end up to figure out the
market name of it before finding out where to look for the BSP. This
split may be important, or not, depending how Freescale intend to
release the SDK (which will have the BSPs on it).

In case all BSP are in sync with Yocto GIT and no internal forks are
used, it might be good to have the split as each SoC might have
different responsable team (even though I still believe it all needs
to be tested together to ensure it all work fine in this case) however
if the SDK will use internal forks and have a not synchronized release
with Yocto so it is less important as Freescale will be able to merge
the public and community driven BSP at any time and use it as base for
next release.

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