linux-linaro-core-tracking tree created

[John Stultz]

On 04/24/2012 08:24 PM, Andy Green wrote:
> On 04/25/2012 11:12 AM, Somebody in the thread at some point said:
>
>>> We're still undergoing uplevel on tilt-tracking and didn't get back to
>>> tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we
>>> have a fix for that today), so I put off this common config thing.
>>>
>>> However now I see it included, aren't most of the patches about board
>>> support redundant?  If LTs base on this, they will add in their own
>>> golden initial defconfig for their board(s) at that point; when they're
>>> combined they'll all be in the combined tree.  It seems like I shouldn't
>>> be seeing a defconfig about Panda coming in with this base tree, but
>>> create it (perhaps after mixing in config fragments that did come in
>>> with the base tree) in my tree.
>> We could just have the fragments per topic, and then the LT can decide
>> either to add another fragment, or simply creating an entire different
>> config to be used by default.
>>
>> Having everything in config fragments may help automating the builds,
>> but I understand that having one defconfig might also help people that
>> are consuming the tree directly.
> Yes I'm not really referring to fragment process here, I understand the
> idea and as I wrote expect the common one(s) to come in with this base tree.
>
> What I'm talking about is ./configs/panda.conf brought in by this
>
> http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=36f22ea6ac55d44026d374669cb55c60bb366d4e
>
> actually, now we don't maintain anything directly equivalent, we only
> have omap4plus_defconfig that builds a single kernel that runs with
> everything we support, including OMAP543x.
>
> I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda
> config.  But what we're going to provide, and what's meaningful and
> tested with our tree, will be this omap4plus_defconfig that appears in
> our topics.  panda.conf that we are inheriting from this basis branch
> may not even build with our tree, it's at least confusing to have it
> there and at worst it'll mislead end users, rot as we go on etc.
Yea, it was added mainly for demonstration purposes for how the config 
fragments might work.
(It also is something I use for my panda on android testing, but that 
doesn't warrant it being included).

There may be some need for a config that the (oh the names have changed 
so much I don't know what its called) 
vanilla-upstream-android-builds-for-panda uses.  But I'm happy to locate 
that somewhere else or with a more clear name.

Even so, if you and Andrey have a system that works for the omap config 
fragment, I'm fine dropping the configs/panda.conf

thanks
-john