On 6/27/2012 10:58 PM, Jason Smith wrote:
On Wednesday, June 27, 2012 5:13:25 PM UTC-7, Chris Double wrote:
On Thu, Jun 28, 2012 at 9:00 AM, Maire Reavy<[email protected]> wrote:
* Getting platform decoders working on the Otoro device
This should include something measurable so we can tell if we've met
the goal. Perhaps some videos that must decode and play smoothly, or
details of the class of video that should play. Same with the Android
goal.
* Support getting full getUserMedia working on B2G, as needed (this
remaining work will be done by the B2G team itself, so that is why this goal
says "support")
Goals with 'support' are very difficult to measure. How do we tell at
the end of a quarter if the goal is achieved? If there are specific
things that we need to do to ensure getUserMedia works, then we should
probably list those as the goal.
Chris.
--
http://www.bluishcoder.co.nz
Hi Maire,
To bring the QA perspective in here on this proposal and to get clarification
(since this greatly affects the Desktop QA team's Q3 goals):
- So the goals your aiming for sounds like that only for landing WebRTC - from
the QA side of the world, this would imply someone from our team getting ramped
up on the project and becoming involved and beginning to formulate the test
plan in this area. Does this align with what you are thinking about from a
product perspective?
Yes, during Q3, we're looking to line up code reviews, security reviews
and test plans for WebRTC. We've started some of that work, but there's
a lot more to do.
- getUserMedia in full - sounds like the camera API would be in-scope possibly
for QA support then for Q3, correct? That's dependent on the UI pieces being
there, but having a test plan in place seems plausible to have, including
testing at the API level if possible. Getting ramped up to test this and
provide support seems like that would be in-scope then. Thoughts? Does that
align with what you are thinking?
Yeah, I think it makes sense to put test plans together in the hopes
that the Firefox team will be able to do the UI/front-end work in Q3.
Even if they can't, writing the test plans will not be wasted work. We
will be shipping full getUserMedia with UI; it's just a question of when.
Generally, my interpretation of your proposal makes me think our Desktop QA
team needs to include something along the lines of WebRTC, especially the
Camera API for Q3, even if some UI pieces don't get there. Probably the most
important piece is start getting involved with your media team more, as I don't
think our desktop QA team has started involvement. Then, moving forward with
test planning and providing QA support as needed.
Thoughts? Does this connect well to your Q3 goals you've proposed?
Yes, I think the sooner we start a mutual brain dump of what we need
tested and how you would expect to test WebRTC and related projects
(like getUserMedia and camera API), the better. Randell Jesup (who's
the module owner for WebRTC) and I have been pulling together a
first-cut list of the stuff that needs testing for WebRTC -- which we
hope to have in a shareable state later today or tomorrow.
getUserMedia is a piece of WebRTC, but it's also going to be leveraged
for camera API work. I don't think it's a mistake to create test plans
for camera API in Q3. Anant is the tech lead for getUserMedia and the
camera API work based on getUserMedia. I know he'll help us figure out
how to best test this. And I'm confident camera API is going to become
an important feature at Mozilla in the near future.
FYI: If our WebRTC team can stay on its current track, we'll be landing
the code in mozilla-central during July and August (behind a config
option). We'll then need every bit of time to test it between then and
the end of the year. I'm still hoping we can ship WebRTC in Firefox 18
(which officially releases in very late December/very early January).
Thanks,
-Maire
--
Maire Reavy<[email protected]>
Mozilla
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
