Status of the linaro-2.6.38 kernel

Arnd Bergmann arnd at arndb.de
Mon Mar 28 19:15:24 UTC 2011


On Monday 28 March 2011 20:22:42 john stultz wrote:
> On Mon, 2011-03-28 at 00:06 -0400, Nicolas Pitre wrote:
> > Given those issues, I decided to rebuild the linaro-2.6.38 branch from 
> > scratch to see where that would bring me.  And as could be expected, the 
> > result looks nicer and it is much easier to work with than the current 
> > tree.  For example, this allowed me to merge the latest OMAP support 
> > from mainline as is, including the latest fixes, without any need for 
> > backport work nor major conflict resolution.  Another advantage is that 
> > the commit SHA1 references are now identical in most cases to what can 
> > be found into mainline.
> 
> Oof. So this will cause some pain with the Linaro + Android kernel tree,
> as it is a consumer of the Linaro 2.6.38 tree.
> 
> I could throw out the old tree and re-merge the new Linaro tree with the
> current Android tree and our fixes, but that could cause grief for folks
> pulling from the current tree.
> 
> Maybe as an alternative solution: you could diff the new tree from the
> old tree and apply those chunks to the old tree. That would get us to
> the same spot, but without the rebase. The patch log won't be great, but
> that could be fixed up when you open up the 2.6.39 branch (maybe naming
> it 2.6.39-rc would be best to avoid the same issue in the future).
> 
> 
> But either way, I think the Android tree could probably could survive
> it.

If you worry about the users of the Android tree more than the
git history of it, there may be another option: Take the diff between
the old and the new linaro-2.6.38 and apply that on the Android
tree. After you have fixed up all conflicts you get from that,
do a pull from the new tree and solve ignore all conflicts by reverting
them in the merge.

That way, you have a tree that your downstream can pull.

	Arnd



More information about the linaro-dev mailing list