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

[McClintock Matthew-B29882]

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?

>  * 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 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