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

[Otavio Salvador]

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.

>>  * 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 at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br