The linux-linaro-3.1 branch is open

[Andy Green]

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.

>> While we're talking, I noticed cpufreq topic on the re-ordered tree
>> looks like it's a selfcontained little history for a new governor called
>> 'interactive'.  Do you know anything about the history of efforts to get
>> this upstream?
>
> So its never been submitted that I'm aware of. I've chatted with some
> non-android google folks who do more upstream cpufreq work, and they
> weren't really aware of it.
>
> It was on my list for the trivial-tree earlier, but I never got to it (I
> still need to get the smaller cgroup patches sent out). If you think its

It sounds like I should have put cgroup on its own topic as well.

> more interesting, I can bump its priority and try to get it out for
> discussion. I have neglected the trivial tree work this cycle, so it
> would probably be good to get another item or two our for discussion.

Amit wrote more about cpufreq so I replied there.

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.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog