On Tue, Feb 26, 2013 at 6:29 PM, McClintock Matthew-B29882 <[email protected]> wrote: > On Tue, Feb 26, 2013 at 9:05 AM, Otavio Salvador > <[email protected]> wrote: >> 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. > > 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: [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
