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.
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.
* 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?
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).
thanks
-john
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
