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. 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.
[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'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.
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
As I say Google already seem to have had a go and found attribution merging rather than loss acceptable.
like a fork-of-a-fork to me, and doesn't help with Linaro goals of staying close to upstream (whomever upstream is).
The tree, the files, the diff, though will be the same as before after this kind of patch folding, it will be no closer or further away from its currently hidden upstream. When people talk about 'fork' and 'close to upstream' they usually mean actual changes to the tree.
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.
There's a flow based around git diff and git blame that will allow detection of new patches and integration of changes on top of the same starting point, even if one side has the starting point as raw files with no patch history. I expect that can be automated like the rest of the management I am doing is largely automated now.
If the reorder had caused lots of damage topic by topic that would be a bad problem, but actually it broke apart surprisingly smoothly. Most of the topics have very little or no dependencies outside their little world.
The worst that can happen is Google ignore us and we have to restart tracking with common-3.2 assuming that's available. But reviewing all 470 patches briefly as I did to reorder them, I expect we find 90% of these patches the same in common-3.2 and it's just the additional patches I need to integrate into the topic-based reorder. In the meanwhile, until common-3.2 is coming, I get the advantage of the re-order for tracking uplevelling.
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.
-Andy