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

[Otavio Salvador]

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