Re: Starting a test suite for Web Audio

Tobie Langel writes:

> On Tuesday, May 21, 2013 at 12:16 PM, Chris Lowis wrote:
>
>>
>> Tobie Langel writes:
>> > > The Web Audio WG (of which I am the co-chair, and coordinator of our
>> > > testing effort), have started work on some tests for the Web Audio
>> > > API. You can see our work-in-progress at
>> > >
>> > > https://github.com/WebAudio/web-platform-tests
>> >
>> > Why not include your tests directly within
>> > https://github.com/w3c/web-platform-tests like other WGs are doing
>> > (e.g. WebApps)?
>>
>> I think we are, they're in the master branch:
>>
>> https://github.com/WebAudio/web-platform-tests/tree/master
>
> Sure, but why work off a fork? This alienates external contributors in
> events like TTWF for example, and prevents you from benefiting from
> the tooling we're building, such as the coverage tool.

I certainly don't want to alienate anyone from the effort, quite the
contrary!

Perhaps I've misunderstood something about the github workflow you are
proposing? The readme in https://github.com/w3c/web-platform-tests
suggests working off a fork

"
The way to contribute is just as usual:

- fork this repository (and make sure you're still relatively in sync with it if you forked a while ago);
"

There's some really tricky complexities around testing audio, as it is
quite unlike a lot of the other test suites I have seen. At the moment
our discussions centre around using a ScriptProcesserNode vs an
offlineAudioContext to allow reference tests. I think providing a bit of
extra guidance and a single place to have tests reviewed and discussed
is quite useful. Also, as our spec is a moving target at this stage, we'd
like to try and keep our tests in lock-step with changes to the spec,
via our bug tracker. I think having a place (our "fork") for tentative
submissions where we can discuss them on our list might help with that.

I don't think it precludes us from benefiting from your developments, as
we'll regularly submit the tests our group is working on as a pull request when
we've written tests we're happy with. I expect we'll do that frequently
when we've come up with a sensible testing strategy. We just need a
"sandbox" at this stage.

>> I wanted the default branch on our github page to have some
>> webaudio-specific information (especially contribution legalise and our
>> "submission" workflow), hence the webaudio-readme branch. Does that make
>> sense?
>
> We're aiming for a single, cross-group process and review system here.
>
> If you have special legal requirements or issues with the common
> workflow, please let us now.

No, we don't. Quite a lot of our members are invited experts who only
engage with the W3C through the Web Audio group, I wanted to make the
process clear to them. We do have a number of members who are keen
to get involved with testing Audio specifically, and may need some help
to know how to contribute. You will still be able to review the tests we
write when we send a pull request to
https://github.com/w3c/web-platform-tests, of course.

> We're still in the process of documenting all of these things, so
> now's the right time to help and/or make comments.

Sure - it took me a long time to work it out myself. By creating a fork,
as suggested by your readme, and adding some extra audio-specific
information I'm trying to lesson the barrier to entry for our group, and
hopefully end up with more tests as a result :)

> We've been liaising with browser vendors for a while about this effort
> and are well passed the planning stage at this point. Happy to sit on
> a call with you and discuss the plans more thoroughly.
>
> At this stage we're deep into the funding part of this effort, and
> this is clearly an area where we could use the help of our members.
> Here, again, happy to sit on a call and describe what we're looking
> for more thoroughly.

Thank you! You'd be welcome to join our call, of course. I'll try and
schedule another testing chat into one of agendas very soon.

Cheers,

Chris

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Tuesday, 21 May 2013 11:46:40 UTC