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@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
