Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)
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 but means everyone will be pushing to the same repo which could get a bit messy. (Unless we had an official maintainer to manage all commits to the tree.)
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.
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.
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.
On 11/14/2012 06:11 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?
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
On Wed, 2012-11-14 at 19:06 +0400, Andrey Konovalov wrote:
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?
I guess "basic board config" == config for features in Linus Torvald's tree. "new board enablement" == config for things only in LT tree. For us that's TC2 power managemnt and various drivers. Probably, most of the time the config for this extra stuff in LT trees is harmless (i.e. just gives KConfig warnings) but I imagine there might be things which would break llct.
- 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.
Yes, and we don't use it, instead I cut'n'paste it into vexpress.conf because CI jobs etc want a single config. And now I think about it, this probably doesn't play well with the big.LITTLE In-Kernel Switcher (IKS) project, so that's possibly going to have to patch vexpress.conf to remove MP and add IKS configs.
On 11/14/2012 08:12 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2012-11-14 at 19:06 +0400, Andrey Konovalov wrote:
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?
I guess "basic board config" == config for features in Linus Torvald's tree. "new board enablement" == config for things only in LT tree. For us that's TC2 power managemnt and various drivers. Probably, most of the time the config for this extra stuff in LT trees is harmless (i.e. just gives KConfig warnings) but I imagine there might be things which would break llct.
This makes sense. I see. The "new board enablement" is not for the "board configs" topic for llct then.
Thanks, Andrey
On Wed, 2012-11-14 at 20:30 +0400, Andrey Konovalov wrote:
On 11/14/2012 08:12 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2012-11-14 at 19:06 +0400, Andrey Konovalov wrote:
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?
I guess "basic board config" == config for features in Linus Torvald's tree. "new board enablement" == config for things only in LT tree. For us that's TC2 power managemnt and various drivers. Probably, most of the time the config for this extra stuff in LT trees is harmless (i.e. just gives KConfig warnings) but I imagine there might be things which would break llct.
This makes sense. I see. The "new board enablement" is not for the "board configs" topic for llct then.
It's not.
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
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
On 15 November 2012 11:37, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
OK, can we do it then? We're freezing for release today, but it's not a big change, so we can get it in, right?
At some point in the past, Andrey asked:
My question is if this topic branch would be kernel/configs.git,
Sounds perfect
config-boards-tracking branch or something else?
I don't have an opinion. We'll probably have to live with it for a long time, but as long as it looks sensible, I'm sure people will be ok...
On 11/15/2012 04:01 PM, Ryan Harkin wrote:
On 15 November 2012 11:37, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
OK, can we do it then? We're freezing for release today,
Are we? https://wiki.linaro.org/Cycles/1211/Release/Calendar?highlight=%28release%29...
but it's not a big change, so we can get it in, right?
At some point in the past, Andrey asked:
My question is if this topic branch would be kernel/configs.git,
Sounds perfect
config-boards-tracking branch or something else?
I don't have an opinion. We'll probably have to live with it for a long time, but as long as it looks sensible, I'm sure people will be ok...
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 15 November 2012 12:38, Andrey Konovalov andrey.konovalov@linaro.org wrote:
On 11/15/2012 04:01 PM, Ryan Harkin wrote:
OK, can we do it then? We're freezing for release today,
Are we? https://wiki.linaro.org/Cycles/1211/Release/Calendar?highlight=%28release%29...
Doh!
Looks like I'm a week early... makes a change... ;-)
On 11/15/2012 05:31 PM, Ryan Harkin wrote:
On 15 November 2012 11:37, Jon Medhurst (Tixy) tixy@linaro.org wrote:
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
OK, can we do it then? We're freezing for release today, but it's not a big change, so we can get it in, right?
At some point in the past, Andrey asked:
My question is if this topic branch would be kernel/configs.git,
Sounds perfect
config-boards-tracking branch or something else?
I don't have an opinion. We'll probably have to live with it for a long time, but as long as it looks sensible, I'm sure people will be ok...
config-boards-tracking branch already has got config fragment for Origen board, but this config file has enabled all the config options used in all the topic branches too. If we plan to keep it that way, I suggest to add the basic board config file to config-core-tracking. (It makes sense as we would be enabling only mainline components that is essential to boot the board). Any further modification to these can always be done through LT topic branches.
Andrey, let me know which way you would prefer the patch?
On Thu, 2012-11-15 at 11:37 +0000, Jon Medhurst (Tixy) wrote:
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel packaging jobs support multiple config fragments, so for now we're stuck with one config per board. Shall we agree that all of these will live in the central location of the config-boards-tracking branch of git://git.linaro.org/kernel/configs.git ?
On 11/15/2012 06:05 PM, Jon Medhurst (Tixy) wrote:
On Thu, 2012-11-15 at 11:37 +0000, Jon Medhurst (Tixy) wrote:
On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote:
On 11/14/2012 07:41 PM, Ryan Harkin wrote:
On 14 November 2012 11:38, Jon Medhurst (Tixy) tixy@linaro.org wrote:
[...]
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.
I agree.
Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel packaging jobs support multiple config fragments, so for now we're stuck with one config per board. Shall we agree that all of these will live in the central location of the config-boards-tracking branch of git://git.linaro.org/kernel/configs.git ?
Fine with me as long as the basic board config gets pulled into llct. I will post the Origen patch today.
On Fri, 2012-11-16 at 09:11 +0530, Tushar Behera wrote:
Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel packaging jobs support multiple config fragments, so for now we're stuck with one config per board. Shall we agree that all of these will live in the central location of the config-boards-tracking branch of git://git.linaro.org/kernel/configs.git ?
Fine with me as long as the basic board config gets pulled into llct. I will post the Origen patch today.
Andrey, shall I'll sent you patches to add vexpress.conf to config-boards-tracking or just do it myself?
Other news, John Rigby has just enabled the Ubuntu kernel packaging CI jobs to support specifying multiple 'board' config fragments; the caveat being that they must all live in the same git repo. That should be OK if you integrate all the config fragments into the branch you are building, like I do, and like we'll have with llct and any branches based on top of that.
As an example, for vexpress we would be able to specify
board_config_frags="linaro/configs/vexpress.conf \ linaro/configs/big-LITTLE-MP.conf \ linaro/configs/vexpress-lt.conf"
Where vexpress.conf is the basic vexpress config for upstream code, big-LITTLE-MP.conf is from PMWG, and vexpress-lt.conf if from the ARM LT tree with the new bits.
On 11/15/2012 07:50 AM, Tushar Behera wrote:
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.
Yes, only the basic board configs are for LLCT.
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
-
Andrey Konovalov -
Jon Medhurst (Tixy) -
Ryan Harkin -
Tushar Behera