On 27 May 2011 11:45, Deepak Saxena dsaxena@linaro.org wrote:
On 26 May 2011 20:17, Zach Pfeffer zach.pfeffer@linaro.org wrote:
My only comment is on:
What We're Not Doing
Integrating graphics drivers ● Handled by vendor Landing Team
I think aspects of this will need to be handled by the kernel team. Especially with the work Jesse and the MM summit are proposing.
Hi Zach,
Clarification on the above point is that we will not be handling integrating binary blobs for the different SOCs. Any work that Jesse's team and upstream developers do on consolidating towards a single buffer management solution will certainly be integrated into the linaro-linux tree as it starts stabilizing.
We're going to need to chat about that. I'll need support for binary blob integration from all teams. Overall I'm asking for each team (Landing Teams included) to:
(Thanks to Michael Hope for suggesting this list)
1. Build the working group output and Android combinations with each commit (CI) * Build last-known-good Android with latest working group output * Build latest Android with last-released working group output * Build latest Android with latest working group output 2. Smoke test (CI/test farm) * Load onto a board * Run a test script * Run 0xbench 3. Report any build or smoke test failures (CI) 4. Report any performance regressions (CI) 5. Document Linaro improvements in general and on Android, how to build the component and how to get it. 6. Add benchmarks to showcase Linaro improvements. 7. Add tests to test functionality.
Some of this will be automated with Gerrit eventually. Until then it'll be a manual process.
-Zach
W dniu 30.05.2011 17:48, Zach Pfeffer pisze:
We're going to need to chat about that. I'll need support for binary blob integration from all teams. Overall I'm asking for each team (Landing Teams included) to:
(Thanks to Michael Hope for suggesting this list)
- Build the working group output and Android combinations with each
commit (CI)
- Build last-known-good Android with latest working group output
- Build latest Android with last-released working group output
- Build latest Android with latest working group output
- Smoke test (CI/test farm)
- Load onto a board
- Run a test script
- Run 0xbench
^ this is obviously lava
- Report any build or smoke test failures (CI)
- Report any performance regressions (CI)
^ this is in scope for validation dashboard but needs guidance about baselines and expected reporting
- Document Linaro improvements in general and on Android, how to
build the component and how to get it. 6. Add benchmarks to showcase Linaro improvements. 7. Add tests to test functionality.
I'd like to understand which features (except the ones I noted) should be implemented or provided by LAVA and which are out-of-scope and will be provided by external scripting.
Thanks ZK
On 30 May 2011 08:48, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 27 May 2011 11:45, Deepak Saxena dsaxena@linaro.org wrote:
On 26 May 2011 20:17, Zach Pfeffer zach.pfeffer@linaro.org wrote:
My only comment is on:
What We're Not Doing
Integrating graphics drivers ● Handled by vendor Landing Team
I think aspects of this will need to be handled by the kernel team. Especially with the work Jesse and the MM summit are proposing.
Hi Zach,
Clarification on the above point is that we will not be handling integrating binary blobs for the different SOCs. Any work that Jesse's team and upstream developers do on consolidating towards a single buffer management solution will certainly be integrated into the linaro-linux tree as it starts stabilizing.
We're going to need to chat about that. I'll need support for binary blob integration from all teams. Overall I'm asking for each team (Landing Teams included) to:
I agree that we need to talk about it. :) What I'd like to see is clearly identified ownership of who does different integration tasks and I still think that the integration of the binary graphics drivers needs to be handled by the landing teams who then feed into the Android builds. What you're proposing is a parallel model where every group is testing independently and then we throw everything together. What I'm proposing is a linear model where one group feeds their output to another group to add their patches on top and to test against Android at each merge step. KWG provides a linaro-linux + Android kernel to the landing teams who then merge their non-upstream patches and then feed that to the platform team.
It is unclear to me who manages merging all the bits together in the the parallel model of each team testing separately against Android and then throwing the bits together. I'm reading your email as that being the KWGs responsibility but I'm don't think that we have the cycles to handle integration and testing of closed source drivers into our tree w/o having to drop some of our technology enablement tasks for 11.11.
~Deepak
On 31 May 2011 16:54, Deepak Saxena dsaxena@linaro.org wrote:
On 30 May 2011 08:48, Zach Pfeffer zach.pfeffer@linaro.org wrote:
On 27 May 2011 11:45, Deepak Saxena dsaxena@linaro.org wrote:
On 26 May 2011 20:17, Zach Pfeffer zach.pfeffer@linaro.org wrote:
My only comment is on:
What We're Not Doing
Integrating graphics drivers ● Handled by vendor Landing Team
I think aspects of this will need to be handled by the kernel team. Especially with the work Jesse and the MM summit are proposing.
Hi Zach,
Clarification on the above point is that we will not be handling integrating binary blobs for the different SOCs. Any work that Jesse's team and upstream developers do on consolidating towards a single buffer management solution will certainly be integrated into the linaro-linux tree as it starts stabilizing.
We're going to need to chat about that. I'll need support for binary blob integration from all teams. Overall I'm asking for each team (Landing Teams included) to:
I agree that we need to talk about it. :) What I'd like to see is clearly identified ownership of who does different integration tasks and I still think that the integration of the binary graphics drivers needs to be handled by the landing teams who then feed into the Android builds. What you're proposing is a parallel model where every group is testing independently and then we throw everything together. What I'm proposing is a linear model where one group feeds their output to another group to add their patches on top and to test against Android at each merge step. KWG provides a linaro-linux + Android kernel to the landing teams who then merge their non-upstream patches and then feed that to the platform team.
It is unclear to me who manages merging all the bits together in the the parallel model of each team testing separately against Android and then throwing the bits together. I'm reading your email as that being the KWGs responsibility but I'm don't think that we have the cycles to handle integration and testing of closed source drivers into our tree w/o having to drop some of our technology enablement tasks for 11.11.
I think we're going to go through a few stages here. One goal is to run Android on each board everything list here:
http://www.linaro.org/low-cost-development-boards
The eventual goal is to to run the same kernel across all the boards with an Android version of the 'hwpack' enabling all of the great features these boards have to offer: GFX, video, audio, Bluetooth, etc. I think this is doable.
I imagine that the winding road to get there is going to involve a lot of "get everyone in the same room (physically or virtually)" and work through the integration issues that will arise and that can't be easily tracked to landing team, or kernel, or multimedia, or anyone else.
I don't think its out of the scope of the LTs or WGs to test their changes against the Android builds that we're trying to release. Trying to test at the end of the cycle will just mean everything will break. Soon we'll have a continuous integration loop where people can push their changes and have them tested 24 hours a day.We'll also have a breakdown of what's supported on each build.
On Wednesday 01 June 2011, Zach Pfeffer wrote:
The eventual goal is to to run the same kernel across all the boards with an Android version of the 'hwpack' enabling all of the great features these boards have to offer: GFX, video, audio, Bluetooth, etc. I think this is doable.
I would set the goal even higher, and eliminate the need for a hwpack in the long run. For a lot of boards, we can probably do this for everything but the GPU drivers given the current state of licensing, but I also haven't given up the idea that we will one day see working free GPU drivers.
Arnd
-
Arnd Bergmann -
Deepak Saxena -
Zach Pfeffer -
Zygmunt Krynicki