On Wed, 2013-11-13 at 10:23 -0500, Bruce Ashfield wrote: > On 13-11-13 01:59 AM, Darren Hart wrote: > > On Tue, 2013-11-12 at 23:18 -0500, Bruce Ashfield wrote: > >> On 11/12/2013, 4:27 PM, Darren Hart wrote: > >>> On Tue, 2013-11-12 at 15:59 -0500, Bruce Ashfield wrote: > >>>> On 13-11-11 06:25 PM, Darren Hart wrote: > >>>>> The following changes since commit > >>>>> f1c9080cd27f99700fa59b5375d1ddd0afe625ad: > >>>>> > >>>>> meta/common-pc: add missing dependencies for BRCMSMAC (2013-11-03 > >>>>> 23:01:35 -0500) > >>>>> > >>>>> are available in the git repository at: > >>>>> > >>>>> git://git.yoctoproject.org/linux-yocto-contrib dvhart/3.10/meta > >>>>> > >>>>> http://git.yoctoproject.org/cgit.cgi/linux-yocto-contrib/log/?h=dvhart/3.10/meta > >>>>> > >>>>> Darren Hart (4): > >>>>> minnow: Remove eg20t > >>>>> minnow-io: Add feature for MinnowBoard GPIO keys and LEDs > >>>>> minnow: Remove old patches for Ethernet and GPIO > >>>> > >>>> To confirm. We still want standard/minnow to contain these changes ? > >>>> That's what the meta data tells me, but I wanted to be sure. > >>> > >>> No, the new BSP will use standard/base. There is no real need to have a > >>> standard/minnow branch as far as I can see. > >> > >> That's what I was wondering and thinking as well. When I was merging the > >> changes I noticed the minnow-standard.scc still had a branch statement. > >> Did you want to quickly roll that removal into this series while you > >> are updating the meta data ? > > > > I hadn't thought of this. I thought the purpose of the branch statement > > in the minnow BSP scc was to provide a starting point to add anything > > the kernel BSP or the recipe BSP added to the kernel sources - > > independent of whether or not the standard/branch actually existed. > > The branch will be created when the statement is processed. If anything > happens after the statement, the changes go on that branch. > > So by just having it there, you are creating a placeholder branch. > > It is trivial to create the branch later if there really is custom > content. So if you don't want to have it sitting there, then drop > the branch statement for now. > > There are definitely two schools of thought on this. Those that want > to just build from a common branch, and those that follow the > 'branches are simple and cheap' and they document what boards are > supported .. so use them and be happy. > > The tools support both, and we can do either. In different contexts > I'm opinionated one way or the other :)
In that case, having fewer IA branches is more in keeping with the Intel's goals for BSP management. Single-Image, single sources, no vendor trees. I'll respin the series, dropping the branch in the minnow scc files. Some documentation needs to be updated... I'll have to own that. -- Darren > > > > I don't know what best practice is here - maybe we're establishing it > > now. What would you suggest? > > see above. > > > > >> > >>> > >>> I suppose ultimately the BSP branches from standard/base and then > >>> applies the minnow-io feature, but that is meant to be optional at the > >>> BSP (recipe-space) level. > >>> > >>> I'd like *ALL* Intel BSPs to ultimately build from standard/base. > >>> > >>> So - is there any reason to have standard/minnow lying around? I've > >>> removed it from my test builds. > >> > >> How are you working with the minnow-io feature ? I can answer the minnow-io > >> question and the fate of the branch with that answer :) > > > > I plan to have the minnow layer linux-yocto bbappend add minnow-io as a > > KERNEL_FEATURE. This makes it easy to leave it out (which is good as it > > is an abomination of boardfiles). > > Aha. > > The only issue you could run into here is that the patches will be > applied at build time. Which means that if I merge anything to the > base that conflicts, you need to refresh the patches. I hate build time > patch breakage .. since it is the last thing you want to see when just > trying to build a board. > > The only alternative to avoid alternative is to get them on a branch > (*cough* standard/minnow-<foo>) or in that staging branch you had > before, and go with the git merge (but the merge can fail, but at > least the patches can be rebased on the branch to deal with the > conflict and everyone stays in sync). > > Cheers, > > Bruce > > > > >> > >> I ask, because I didn't see it in the series being included or merged > >> (or did I miss it?) from the BSP .scc files themselves. > > > > Right, I didn't even think of it. Open to suggestions. > > > > My current thinking is that we should probably remove it from every BSP > > that starts using standard/base as its KBRANCH - this removes complexity > > from the BSP scc, and that is almost always a good thing in this space. > > > -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto