On Mon, 2012-04-02 at 21:58 +0800, Andy Green wrote: > I don't want to sound like a broken record but we have been doing this > layered config stuff for a long time. It's a very good wheeze and > centralizing some of it will give good results if we can do it in a > good > way. > > Here's an example from our repo. <snip> > When it's available and we're able to, we'll also start putting out a > new flavour branch which has linux-linaro-tracking "flavoured" on to > it, > and just like in lat-3.3 case we will modify the vanilla defconfig > according to what that flavour needs. > > All we require is that the flavour tree, be it > linux-androidization-tracking, or linux-linaro-tracking, comes with a > patch containing the defconfig delta that's meaningful for it.
Those methods are only really applicable if you have all the topics stacked on top of each other. Some other teams won't be doing that. Also, the 'flavour' added onto a basic board config would include topics from working groups as well as the platform specific settings (Ubuntu/Android) and Linaro policy settings. These can't be practically supplied as patches to each separate boards defconfig so they will have to be some mechanism like config fragments and a tool to merge these with the board config. I guess I'm arguing that such a config merge tool be available for use with for board specific configuration, for those teams without stacked topics. And that the inputs to the tool (config fragments) be managed and stored in a way that was intuitively used, e.g. get linaro-bits android-bits board-bits where it doesn't need to reference something outside of the git tree to know what are in the 'bits'. -- Tixy _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
