Bug 885583 will cover part of what needs to be done in order to enable Web Audio mochitests on b2g.

My test patch from bug 885583. https://tbpl.mozilla.org/?tree=Try&rev=b65d117b43f0

Funny story: https://tbpl.mozilla.org/php/getParsedLog.php?id=24543346&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=24545886&tree=Mozilla-Inbound https://tbpl.mozilla.org/php/getParsedLog.php?id=24546254&tree=Mozilla-Inbound, backed out in http://hg.mozilla.org/integration/mozilla-inbound/rev/6e091ce775ef

I'm making this a P2, but we should quickly raise this to a P1 once some of the current P1 bugs have landed.

(In reply to comment #4) > I'm making this a P2, but we should quickly raise this to a P1 once some of the > current P1 bugs have landed. I disagree. We're going to ship code in gaia which uses Web Audio, and we really need to run all of these tests on b2g. I would say this should be P1.

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #5) > (In reply to comment #4) > > I'm making this a P2, but we should quickly raise this to a P1 once some of the > > current P1 bugs have landed. > > I disagree. We're going to ship code in gaia which uses Web Audio, and we > really need to run all of these tests on b2g. I would say this should be P1. I am a strong believer in tests, but what's our path to achieving this? My understanding is that the only gaia feature that uses web audio is the Dialer, and we are focusing on Dialer problems as our top P1 bug (see bug 937505). We currently have 19 P1 bugs (which affect how usable the feature is for various use cases and apps, especially games) and 2 full-time developers (one of whom is about to be away for the rest of December and most of January). Roc is starting to help us out again (you probably saw some of his comments on the Dialer bug), but he has PTO coming up as well. It's almost summer in NZ. I do expect that many of the 19 P1 bugs will help B2G and will help the B2G tests. In some ways those are a stepping stone to enabling the tests. I'm working to get more developers on the project as it makes sense, but adding this bug (and all that it implies) to the other P1 bugs is equivalent to my not prioritizing. As it is, I'm concerned 19 is too many for the size of our current team. If you have developers in mind who would be willing to help with our effort, I'm thrilled to talk with them and help get them involved ASAP. But until we have more folks, we have to make tough calls like this. If you feel there are P1 bugs that should be pushed lower in order to raise this up in priority, I'm happy to talk about that as well. Like I said originally, this is one of the first bugs I will raise to P1 once we have fixed some of our existing P1 bugs (and/or gotten more help).

The thing is, I don't think that this bug should be lower priority than our other P1 tests. It's OK if we mark this as P1 and don't get to fix it immediately, but I'd rather us focus on this bug than any of our current P2 or P3 bugs. Does that make sense? (FWIW if you're using the priority flag in some other way, please let me know -- I'm assuming that it's being used to specify the priority of the bug.)

(In reply to :Ehsan Akhgari (needinfo? me!) from comment #7) > The thing is, I don't think that this bug should be lower priority than our > other P1 tests. It's OK if we mark this as P1 and don't get to fix it > immediately, but I'd rather us focus on this bug than any of our current P2 > or P3 bugs. > > Does that make sense? (FWIW if you're using the priority flag in some other > way, please let me know -- I'm assuming that it's being used to specify the > priority of the bug.) I think we effectively agree already. You're not asking me to prioritize this over any of our current P1 bugs. And I'm saying that this is likely to be the first P2 bug that gets promoted to P1 once some of the current P1 bugs are fixed. As far as definitions go, our P1 bugs are bugs that we are actively working on, that have committed owners, and that we plan to get into the next release cycle (or two), modulo surprises. Right now the current crop of P1 bugs are believed to be costing us developers. As we burn down the current list of P1 bugs, our most important P2 bugs will move up to become P1s and so forth until (in theory) we run out of bugs or are left with a list of low priority bugs we feel we can live with for a while. Having said that, it doesn't mean folks can't and won't work on P2 or even P3 bugs sometimes (i.e. bugs that haven't been promoted to P1). Karl made a good suggestion today (we had a meeting to review P1 bugs) -- which was to get the "offline" Web Audio tests working as a step 1 to enabling all the B2G tests. I think we can squeeze that onto our current P1 list -- and get the rest of the B2G tests onto our P1 list soon after that.

Thanks, that sounds good!

Fixed as part of bug 916135.