On 24/05/12 09:11, Somebody in the thread at some point said:
On 05/23/2012 05:25 PM, Andy Green wrote:
On 24/05/12 06:42, Somebody in the thread at some point said:
Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable?
(If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.)
Pretty much, I think they're saying to their customers, "here's an enabled vanilla tree" and then nobody wants to see problems coming from OOT Androidization series. Since we already had "funny things" in vanilla build from the series, this isn't so paranoid to be concerned about.
I think part of the difficulty here has been the classic question of: A) Is the linaro kernel release a development snapshot of the current state of our work - allowing us to get real world testing of our not-yet-upstreamed work? B) Or is it a stable base for others to build upon?
And the answer so far has been "both!" (we're always optimistic! :) but this is a good example of a case where the integration testing of android code with mainline (which helps resolve issues before pushing upstream) is apparently considered too risky for folks wanting that stable base to build upon.
If we were claiming to be doing something to the OOT Android series (which is not our work at all) to make it more consistent and workable with upstream, it would be easier to explain to people who don't actually want it but might accept some temporary risk for the greater good.
Again, I can see both sides, and what makes most sense depends on our priorities.
Personally I like the idea of the Androidization becoming part of the basis because it puts us in generally converged direction with mainline. But then we have a responsibility to make it as transparent as mainline will insist that it is if we expect members are seriously going to offer vanilla kernels on this basis.
I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined?
Someone needs to audit the OOT Androidization stuff and confirm that for patches that go "out of their box", ie, reach out of /staging or some specific driver:
- the impact of the patch is negated if CONFIG_ANDROID or some more
specific config is disabled, or,
remove the patch as too invasive, or,
conclude the patch is useful and needed in vanilla case too
there's a big variety of "out of the box" patches for stuff like cache code, mmc core, network stack and so on in that series last time I looked. We should give some assurance for people using linux-linaro-core-tracking that someone at least looked at each of those cases and determined its status as above.
Again, this would be great to have. Although the calls being made here also have costs to consider:
- If we remove the patch, we diverge from AOSP, which makes keeping up
with Google's tree more costly.
Not sure we can eat both those cakes, either we're doing mighty feats of engineering on OOT Google stuff to align it to upstream and there may be some dust, or we are just mechanically cloning AOSP OOT content in our mainline tree because we believe any change from AOSP series would be heretical.
- If the patch is needed in vanilla, but might not be acceptable,
considerable work might be required to get it into shape. So what do we do in the meantime?
Unless it reeks too badly, stick it on llct so we get the sinful benefits and switch to the clean version when it comes from mainline. That's interesting to tree consumers because path through mainline can often be very twisty and slow, yet inbetweentimes mainline lacks the feature and we have it. If that's true of dozens of pending features at any one time, yet our tree is overall consistent with direction and basis of mainline, our tree is looking pretty hot.
Further, for the various bits that are not config switched, any such review would need to be done by domain experts, as much of the changes (especially with regard to arm architecture and mmc tweaks) are well beyond my/a novice's ability to audit. In some cases where I've pushed seemingly trivial fixes from the AOSP stack to lkml, Russell and others have not been able to come to consensus as to if the fix is correct or not, so this definitely isn't a trivial work.
And all of the above suggestions you've made are desired, but given time constraints we've been focusing on the more generic functionality first, and moving from there to the more specific driver and architecture changes (which is where the majority of the un-config switched changes are). Its just taking some time to get there, so I suspect pushing the linaro-android tree into a separate merge tree is likely the easiest solution at this point to address your concern (assuming the loss of integration testing is deemed as ok).
Putting it another way if Linaro isn't going to take even a modest amount of care about the OOT Android content making problems in vanilla case, we probably aren't ready to add this lot to a vanilla basis. Irritating as that is for me as much as anyone.
-Andy