On 04/26/2012 01:54 AM, Somebody in the thread at some point said:
Hi -
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.
Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch.
It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side.
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?
No, it wasn't. In the Android patchset all their new config options are "y" by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to "n", and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS).
Right that's what's needed. I'll just wait for this to go away as we track -core then.
As I mentioned before the LT trees also have some config mistakes like this that never show up on their tree because the stuff is always configured on. When they're combined, several small - trivial - Kconfig bugs to fix like that will shake out from all over. When we start seeing complaints about that, I'll know we're really getting our teeth into combining trees.
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,
yes (this comes from the "unsorted" topic wich I am going to drop from this tree) ...
Fine.
but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree.
...and yes
Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything.
Very good. I was thinking about creating (reusing actually) linux-linaro-tracking branch to be the linux-linaro-core-tracking plus the LT's topics. But I still have quite a long TODO list, and linux-linaro-core-tracking and linux-linaro branches are higher priorities for me. So no commitments WRT linux-linaro-tracking at the moment :)
Well, it's not like I'm in a rush for it. But if we're not piling on more LT trees aimed at 3.4 soon, we probably don't get a meaningful combined tree for 3.4 release. (I don't think ARM LT content + one other LT tree tells us much since great as ARM LT stuff is, it's not a full BSP tree like other LTs but just introduces novel features that have nothing to conflict with except the odd Makefile one-liner).
Generally if all LTs are basing and tracking on -core, 90% of the integration-readiness job is done. So long as there's not too much off-piste content showing up in diffstat from anyone, you'll likely be surprised how easily they go together at that point (plus or minus inevitable "surprise" from each tree that another tree had also patched that Kconfig / Makefile now).
-Andy