On 04/04/2012 01:02 PM, Jon Medhurst (Tixy) wrote:
On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote:
On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote:
I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees.
As for the board specific fragments, I feel it would be better if the config-upstream tree has the initial fragment (which I suppose is minimal enough to compile the common kernel). That way anyone taking linux-linaro-tracking can have at least a working setup.
I thought linux-linaro-tracking was going to operate a bit like linux-next, i.e. just a merge of all the topics from LTs and working groups, and from which Linaro produces it's releases and does some CI build+test. If that's true, then anyone using that tree will always have the LT code.
In some cases, the mainline kernel cannot boot a specific board using the default config file. If we have a config fragment that adds the necessary changes, people can use that specific board even if LT has no other enablement patches merged to linux-linaro-tracking.
An example would be the thermal patches, which got merged to linux-linaro-tracking through PM WG. But for someone to validate those changes, they won't have a definite config to build linux-linaro-tracking and run on Origen board. Hence I feel that having a minimal board fragment, that boots the kernel till console, in linux-linaro-samsung would be helpful.
As long as we have same set of commits in our tree, we won't have merge conflicts too.
Though I guess if LT code breaks other boards and has to get temporarily dropped, and if that LT code was pulled in as one monolithic topic like TI and Samsung trees, then it would probably mean dropping the board config too if we had that coming from the LT tree. But in that case, does it matter that the broken board can't be built from linux-linaro-tracking?
That is one concern from my side too, as to how do we build linux-linaro-tracking kernel and what all things goes into that.