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/#%21/linaroorg - http://linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev