Config fragment for Versatile Express
andy.green at linaro.org
Tue Apr 3 01:05:32 UTC 2012
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
>> Here's an example from our repo.
>> 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
>> 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
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 Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
More information about the linaro-dev