On Wed, 2011-10-12 at 08:40 +0800, Andy Green wrote:
On 10/12/2011 05:44 AM, Somebody in the thread at some point said:
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.
I don't know your basis yet, I'll be doing the zero-diff thing today.
I took a quick look and it seemed like mostly bits from 3.1-rc code. But I could have missed some items.
But it would have been easier if we had cooperated on the same tree directly. Zeroing the diff will mean the outcome is the same just you redid our initial work, and I have to do additional work to hide the difference in the result. It doesn't feel like we found the smartest approach to work together this time.
I really didn't do much work at all. Only merging, minor fixes, and testing. I can also rebase onto your tree if you think its a big issue. It just sounded from above that you wanted to adjust things in your tree. I apologize for my confusion.
[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.
Do you know who was saying that inside Google?
I think it was Dima? I had asked if they would consider doing topic branches (very similar to what your doing) so picking things out for upstreaming would be easier. He said it sounded interesting, but if they would go through to break things out, they would also want to clean things up (ie: folding) and that's just work they haven't ever had time for.
My impression was that their attention was very much elsewhere from the kernel/common tree, and that they saw it as a bunch of needed legacy stuff they have to carry along with as little effort as possible.
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.
I don't think we need to worry about attribution, already in the patchset the authors took the approach to bring in the changelog from the folded patchsets into the resulting one. We can just follow that scheme.
Just voicing my concern.
[snip]
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.
I don't seem to have reached the attention of the common- guys at Google yet. I agree it would be best to clean the thing in cooperation with Google guys so we can pre-clear the approach for each topic.
I can sympathize with the difficulty of getting the attention of Google developers. :)
thanks -john