On 04/25/2012 07:12 AM, Ricardo Salveti wrote:
On Tue, Apr 24, 2012 at 11:22 PM, Andy Greenandy.green@linaro.org wrote:
On 04/25/2012 03:43 AM, Somebody in the thread at some point said:
Hi Andrey -
I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what "core" implies). This
Nice job, thanks for the new branch which definitely solves the "chicken-and-egg".
In fact it's going to be a great tracking "fake future upstream" staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide
+1, hopefully that will make the LT life easier (specially yours, as you're maintaining tons of patches).
I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 -> #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was.
http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git%3Ba=summa...
Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional?
We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing.
However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default.
Agreed. This looks like something we should be moving to.
Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly.
We could drop these defconfigs from linux-linaro-core-tracking while keeping them in the linux-linaro branch. One of the reasons for these defconfigs are the ci builds and tests: we must have the kernel configuration for every supported board in the tree. There is no requirement for this kernel configuration to be the defconfigs. It could be some script (in the tree) to produce the configs from the fragments, or whatever else.
Thanks, Andrey