[linux-yocto] [PATCH v2 0/4][3.10][meta] MinnowBoard and Wifi updates

[Darren Hart]

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