On 04/03/2012 02:39 AM, Somebody in the thread at some point said: > 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.
Right, that is the source of the different thinking and approaches. Merge-based process is not equivalent to serialized rebases. However as seen where merge-based process has to fall back to being serialized rebases due to topic dependencies ^^ they are not a million miles from each other either. > Also, the 'flavour' added onto a basic board config would include topics Well, "some flavours" rather than "the flavour", but yes. > 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. Yes I was showing how we managed it until now. The new system AIUI will give a new power to "assert config deltas" using this new script (so you can graft on like mostly-allmodules for distros easily). If it's workable for us we'll probably move to using the same script and config delta files, which is why I am engaging on this thread. > 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'. As I see it the config deltas need to come from the flavouring branch. They won't be a patch on the LT-specific defconfig like I showed we do now, the flavouring branches should each contain a config delta file like ./somewhere/linaro-androidization-tracking.config, eg ./somewhere/<original branchname>.config. That way we avoid needing a special central config repo and the guy who works on the flavouring tree can ensure his config delta is always in sync with whatever version of his tree you pulled. Scripts who know which branch they're merging or rebasing can easily find the correct, contemporary config delta needed by the branch (doing it with separate central config repo would suck if you want to get config delta out of it to match random old version, from a tag say, of flavouring tree. If the config delta is in the flavouring tree, that just works). AIUI all I need to do then is adapt my topic management scripts to check for such a file and create a patch to capture the changes from running the "assert config deltas" script for what's being as part of the rebase action on my specific defconfig, and it will be transparent. -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
