Config fragment for Versatile Express

Wed Apr 4 14:07:56 UTC 2012

Hi,

On 2012-04-02, at 5:45 AM, Andy Green wrote:

> 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 
>> 
>> configs/linaro/base/
>> configs/linaro/android/
>> configs/linaro/ubuntu/
> 
> 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
> topic.
> 
> 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 all modules.

Just as a proposition for the management of all these config files that you may already have discuss...:

Why not keeping one defconfig by board with all the latest dev in it and managing a script that fulfil the needs of dev and build server by adding the default config of linaro, android and ubuntu? Why not having a centralized place (git tree config) that keep the default linaro, android and ubuntu config files? 

// Script that use merge_config to validate that defconfig contains config set and add them if not:
linaroConfigAdder.sh -android defconfig
linaroConfigAdder.sh -ubuntu defconfig
linaroConfigAdder.sh -linaro defconfig

Question, why are you not adding the linaro config in the defconfig by default?

thx

KA

> 
> -Andy
> 
> -- 
> Andy Green | TI Landing Team Leader
> Linaro.org │ Open source software for ARM SoCs | Follow Linaro
> http://facebook.com/pages/Linaro/155974581091106  -
> http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
> 
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev