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 allmodules. -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
