Config fragment for Versatile Express
andy.green at linaro.org
Mon Apr 2 09:45:50 UTC 2012
On 04/02/2012 05:31 PM, Somebody in the thread at some point said:
> On Sun, 2012-04-01 at 20:59 +0400, Andrey Konovalov wrote:
>> On 03/31/2012 01:17 PM, Jon Medhurst (Tixy) wrote:
>>> On Fri, 2012-03-30 at 10:15 -0700, John Stultz wrote:
>>>> In that case, just go ahead and push the full config to the config tree.
>>>> If we need to do have fullly-enabled vs upstream builds we can deal with
>>>> the warnings in the latter case (or maybe further split the board
>>>> configs into -upstream and -lt ?).
>>> So this means Landing Teams should host the configs for their boards and
>>> you will host the linaro-base, ubuntu and android fragments?
>> We could have a separate topic branch for the linaro-base and ubuntu and
>> fragments (not board specific), as there is no linaro-base or ubuntu
>> topic in linux-linaro. Otherwise the generic features (not board
>> specific) should also add the config fragments to their topic branches.
>> So the android fragment could live in the android topic as well.
> I'm not sure I follow this, can you give some examples of what files
> live in what repos in what branches?
This is all being made up as we go along, nobody is using this new flow yet.
> The things we need to know is:
> - What config fragemnts is the LT the origin of?
I think we have to provide a minimal, working, defconfig like we do now
and that is the starting point for everything else piled on top.
> - How these should be organised.
> - Where I get the rest of the config fragments from which I need to
> build and test the LT tree for Ubuntu and Android.
> One suggestion...
> Have a directory structure like
I don't think this is a good way. There are two things we found having
already being doing "config fragments" for about a year in TI LT repo.
- having multiple defconfigs is a mistake, they will diverge
- the fragments themselves rot quickly from changes in mainline, both
by way of defaults changing and diffing the defconfig not being a
perfect fit for what it represents (the defconfig is an output of
another process out of sight with its own inputs, so the patches in the
tree changing it are not the only things touching it). In particular
it's almost impossible to hold the line with multiple finegrained config
changes in one topic, we now squash everything into one config patch per
By way of example, previously we ran a different defconfig for android
and vanilla, now we patch the one defconfig when we add Androidization
patches. That means the Android build always gets the latest and
greatest stuff same as vanilla, plus whatever it needs specially.
Don't forget we won't be basing on linux-linaro-tracking, but vanilla.
So that means we'll be producing linux-linaro-tracking "flavour
branches" which can apply the "linaro house rules" for defconfigs such
as being more like allmodules.
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
More information about the linaro-dev