On Tue, Feb 26, 2013 at 5:15 AM, Luo Zhenhua-B19537 <[email protected]> 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: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
