[meta-freescale] Please review the proposal of FSL Yocto layers reorg

Tue Feb 26 13:54:01 PST 2013

On Tue, Feb 26, 2013 at 3:43 PM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> On Tue, Feb 26, 2013 at 6:29 PM, McClintock Matthew-B29882
> <B29882 at freescale.com> wrote:
>> On Tue, Feb 26, 2013 at 9:05 AM, Otavio Salvador
>> <otavio at ossystems.com.br> wrote:
>>> On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537
>>> <B19537 at 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 at ossystems.com.br  http://www.ossystems.com.br
> Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale