On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@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?
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.
(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? 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.
I suppose we are talking about the basic board config here. That should be ok. The new board enablement config fragments should always go in with the respective topic branches.
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
- 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.
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.
Cheers, Ryan.
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev