On 11/14/2012 06:11 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) <t...@linaro.org> wrote:
Adding linaro-dev list and replying with some comments...
On Tue, 2012-11-13 at 20:20 +0400, Andrey Konovalov wrote:
The llct tree itself has no suitable .conf or defconfig for vexpress at
all. That's the problem (wrt the ci jobs).
The easier way seemed to be a single kernel/configs.git,
config-boards-tracking branch to provide the config fragments for all
the llct jobs.
But it creates several instances of the same <board>.conf files and adds
confusion. Agreed.
Should we do in the jenkins jobs something like 'git checkout
arm_lt/integration-linaro-vexpress.conf -- linaro/configs/vexpress.conf'
for vexpress and similar (but different and unique) command for the
other boards?
Yes, I see the problem. But getting CI jobs to pull configs direct from
an LT tree seems like the wrong solution. I guess what people really
need is configs in linux-linaro-core-tracking (llct) (I'm sure people
have told me that before and I possibly didn't listen enough).
Now that the LT branches included in linux-linaro (ll) are based on
llct, then they could modify the board configs in llct if required for
the work in their topics. So at the moment, I can't think of a good
reason not to pub all the board configs into llct. Can anyone else?
Having the boards config fragments in llct is fine for me. Advantageous
even.
I don't know if we need the board configs to be sourced from a single
repo, or allow board configs to be included in llct from LT trees. One
central repo means that people know where to go
This seems like the easiest option to me. Let's do it this way unless
someone gives a valid objection.
llct can only include topic branches. So I need to pull all the board
configs into a single git branch anyway. See no big reason not to make
this topic branch public (== the central repo known to people).
My question is if this topic branch would be kernel/configs.git,
config-boards-tracking branch or something else?
(Unless we had
an official maintainer to manage all commits to the tree.)
I assume this would have to be Andrey. Andrey, are you OK with that?
I am OK with that. Seems I just have no other choice :)
Just don't expect a lot of intelligence from me in this role, and be
prepared to dumb questions when something is not good with the board
config fragments.
Or does someone else need to do it?
Each LT that is using LLCT would have to send a patch to get their
config updated. So long as this happens in a timely manner, LTs
should be able to live with that process.
Updating the board configs in the topic branch and the LLCT could be
tied to the scheduled LLCT updates - every Tuesday that is. And on
request if there is something urgent.
As for me, the board configs are good, as long as the resulting kernels
build, boot ok in LAVA, and pass basic LAVA tests.
Or course, once Linaro's build and test infrastructure supports config
fragments fully, then we could have have separate config fragments for
- basic board config
- new board enablement
Not sure if I follow this 100%... Can I have an example of "new board
enablement" vs "basic board config" config fragment?
- special features (e.g. big.LITTLE MP)
- testing or benchmarking config
and the configs could live in the tree relevant to the code they apply
to rather than having a single central board config we have to manage.
There is already big-LITTLE-MP.conf in the LLCT tree which comes from
the big-LITTLE-MP topic.
That sounds scarey - there would be no one place to get a config, but
I guess, if you need a config for feature X, you'd also need the
branch for feature X that contained the source and config, so it would
work out fine.
Yes. This is the case for big.LITTLE MP, and hopefully the other
upcoming topics would follow this as an example. In the "testing config"
case, I wouldn't be surprised by a topic being just the config fragment
(provided that all the relevant code is already in the tree). Then for
building and testing the stuff in e.g. the LLCT, one would need just to
specify the list of the (in the tree) config fragments to use. (But the
build infrastructure should allow using the config fragments from other
repositories/branches too.) The board config fragments would go into the
LLCT via the board configs topic.
Thanks,
Andrey
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
