The linux-linaro-3.1 branch is open

john stultz johnstul at us.ibm.com
Tue Oct 11 21:44:35 UTC 2011


On Tue, 2011-10-11 at 16:08 +0800, Andy Green wrote:
> On 10/11/2011 02:43 PM, Somebody in the thread at some point said:
> > On Tue, 2011-10-11 at 11:49 +0800, Andy Green wrote:
> >> On 10/11/2011 11:43 AM, Somebody in the thread at some point said:
> >>> Cool. In the absence of a official Android 3.1 common tree, I sat down
> >>> today and actually did the same with the TI omapzoom p-common tree (just
> >>> adding the linaro+android defconfigs and base origen support).
> >>
> >> Is there any reason not to base off my version of it?  There's no
> >> guarantee TI's tree will go on for any longer than they have a use for
> >> it whereas I am planning to do this for a whole cycle.
> >
> > No specific reason not to, just that from reading your announcement from
> > last week, I thought the p-android-3.1 branch was just the rebased
> > android common tree, and it wasn't clear if the tilt tree had other
> > things in it or not.
> 
> What Jassi did was take the TI tree and compare it against the 
> common-3.0 we last had.  He found some missing patches about gadget IIRC 
> and brought them over additionally.
> 
> linaro-androidization-tracking doesn't have anything else on it at all 
> except vanilla + stuff from TI and common-3.0 filling in the gaps.
> 
> >>> There were a few usb related mis-merges in that tree that wouldn't
> >>> compile, so I fixed up. I'm guessing you've already hit and fixed them
> >>> as well, but if not, you can just grab it, its here:
> 
> I think what I'll do is study the diff between the two trees with an aim 
> to reducing that to nothing hopefully by moving things around slightly 
> on my side.
> 
> It won't help anyone to have different versions of "common-3.1" floating 
> about, especially if you think about after 3.1 release your new one will 
> branch off and become release-based and mine will continue into the 
> mysteries of -rc0, if we get Android bugs coming on one but not the 
> other it won't help if there's some lingering question about how they 
> may have differed to start with.

Sounds like a reasonable plan. Although, given that we both started with
the same omapzoom branch (or am I mistaken with that?), I suspect we're
likely to be pretty close already.


[snip]
> Thinking about what's in the topics it seems there are quite a few 
> opportunities for patch folding / consolidation / optimization, ignoring 
> upstreaming.  A few times in one topic a patch is introduced and then 
> reverted, or the patch is introduced and a little later there is a 
> cleanup patch.  It should be at least arguable to fold these, trying to 
> keep track of who did what in the commit log.  (Good example is ion 
> topic, there are 12 "history" patches that could be folded into the 
> first one).
> 
> It complicates the question if this tree 'has' xyz patch, but it 
> simplifies the patchset.  I think 467 patches was enough for this it 
> might be good if it shrank considerably rather than keep on acquiring 
> its own history.

Indeed, it would be very nice if the patch set was condensed. Google
Android devs have admitted the tree could use a heavy cleanup, but so
far it seems they won't invest in doing so.

I'd hesitate to recommend folding the patch set yourself, unless the
fixes being folded in are *extremely* trivial. As a general rule, with
patches that are the works of others, its usually best to check with the
patch authors before folding. Otherwise you diminish the history of the
work, and possibly reduce the credit deserved to those who submit
fixes. 

Although, I admit that its unlikely such folded patches would get pushed
directly upstream, reducing the concern that the rewritten history of
the work would end up fixed in stone upstream. But it still feels a bit
like a fork-of-a-fork to me, and doesn't help with Linaro goals of
staying close to upstream (whomever upstream is).

Additionally, I worry that with a heavily reordered and folded patch
queue, it might be difficult whenever android.git.kernel.org returns, to
sync up with updated Google trees. But I'll leave the weighing of that
trade-off with the benefit of handling fewer patches to you.

All that said, I think in future talks with Google devs, we should see
if there is not some way for us to help them clean up the patch set.
Possibly just by pointing them to your topic-ized tree to see if they
could start with that for their next cycle, and hopefully do the more
obvious folding themselves.

thanks
-john





More information about the linaro-kernel mailing list