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