On 6/27/2012 8:13 PM, 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.
Yeah, I've been thinking about this a lot over the last couple of weeks
since we talked about what does "working" mean for platform decoders,
which are very dependent on the device they are running on.
I think for each device (Otoro in the short term) we need the B2G
platform decoders to perform at X% of default video playback (a device
just out of the box running Android) where X is probably somewhere
between 80-100. For example, if a video can't play on a device using
default software, then we can't expect our B2G platform decoders to be
able to play it. And vice versa: if a video decodes and plays smoothly
using the default software, it makes sense to expect the same (or nearly
the same) on B2G.
I think we can apply the same reasoning to Android: if a video decodes
and plays smoothly in the default browser on Android, it should decode
and play smoothly in Firefox.
I think for Otoro we want someone, perhaps someone in QA, to create a
list of videos that decode and play smoothly on the default device/phone
(fresh out of the box). If it is someone in QA, they'll need guidance
on what videos make sense to test based on our reading of the device's
spec and what we've found out during development on that device. So I
think defining "working" (which includes agreeing to a set or class of
videos for the tests) for Otoro is part of the quarterly goal. And I
think the same is true for the Android goal.
So we could restate the Otoro goal as "Help define a set of videos that
tests platform decoders functionality on the Otoro device and make sure
that platform decoders decode and play smoothly for those videos on the
Otoro." We could reword the platform decoder goal for Android goal in a
similar way.
* 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.
To the best of my knowledge, the getUserMedia work for B2G doesn't need
help from anyone outside of the B2G team, but... what's the old
expression? "never say never"? :-)
With that in mind, this goal is better stated as, "Prioritize B2G work,
wherever necessary, to ship B2G version 1 as quickly as possible."
At this point the B2G team doesn't know what problems they're going to
run into prior to shipment. I realize this is a painfully obvious
statement, but that fact is very relevant to how we word our goal. And
we, along with every other team in Mozilla, needs to be prepared to drop
whatever we're doing if the B2G team needs something from us.
Practically speaking, I think this reworded goal will be a
straightforward goal to meet because the measure of success IMO is: did
we prioritize B2G over other projects when necessary? If the answer
is yes, we've met the goal. I think it's important to have a goal like
this so that we're all on the same page that the B2G work isn't done yet
and still trumps everything else this quarter. I also think it's
important we be recognized that this is what we're doing -- especially
if another Q3 goal suffers as a result.
Cheers,
-Maire
--
Maire Reavy<[email protected]>
Mozilla
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
