On 2012-04-04, at 10:07 AM, Kevyn-Alexandre Paré wrote: > 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
Further reading just respond to my answer sorry for that noise. But for an outsider understanding Linaro workflow is really hard to understand and also the fact that all your workflow are different and requires different needs add to this complexity. Wiki should be nice to explain your final work flow at the end with which specific requirements it fulfil?! 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
