On 04/04/2012 06:20 PM, Somebody in the thread at some point said:
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.
That's a slightly different issue. If stuff that's too avant garde is put into linux-linaro-tracking it'll break one or more lt trees in a way that can't be quickly fixed.
This was seen in January where I tried to base on it, it broke my tree, called for help, got ignored for weeks until it was too late to care about that release because tracking had moved on.
In the end LTs can only help solve issues that fall into their areas of competence, which is far from infinite. If enough next-y stuff is shovelled into linux-linaro-tracking and we're left to it, it'll break all the LT trees. But I think that's understood and there's some attempt to keep it sane and hopefully now take care of any damage it causes.
The big problem in front of us today is "how well do the LTs trees fit together right now as a starting point?". We don't seem to be trying to bind the available trees at v3.3 together at the moment so we can understand our situation for some reason. Instead we're trying to use a single LT tree as an exemplar for a process that is all about binding all the trees.
Maybe we should take some time to do a full scope trial run and start making the small improvements that will be needed for them to slot together well ongoing.
-Andy