Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/23/13 12:48 AM, "Julian Aubourg"  wrote:

>I love the idea of moving to github.
>The one-repo idea, while much simpler from a maintenance point of view,
>could easily be a burden on users that subscribe to it. Even more so for
>people who can merge PRs (and thus will receive an email for a PR
>initiated for any spec).
>
>Not saying it is blocking but it's something to keep in mind. Mail
>filters can go a long way here but filtering out specific specs kinda
>defeats the purpose of having so many eyes looking at everything.

It's also worth thinking about which solution will have more chances of
fostering a community of external contributors and reviewers. Strong but
very specialized contributors might not get noticed. Being the biggest
contributor to the XHR test suite might carry a lot more value than being
the 50th biggest contributor to W3C tests in general.

--tobie

Re: Proposal: moving tests to GitHub

[Julian Aubourg]

I love the idea of moving to github.

The one-repo idea, while much simpler from a maintenance point of view,
could easily be a burden on users that subscribe to it. Even more so for
people who can merge PRs (and thus will receive an email for a PR
initiatedfor any spec).

Not saying it is blocking but it's something to keep in mind. Mail filters
can go a long way here but filtering out specific specs kinda defeats the
purpose of having so many eyes looking at everything.

Le mardi 22 janvier 2013, Robin Berjon a écrit :

> On 22/01/2013 17:14 , Tobie Langel wrote:
>
>> On 1/22/13 4:45 PM, "Robin Berjon"  wrote:
>>
>>> You *do* need to make the proper commitments for the test suite, but
>>> those are much lighter and can easily be extended to all.
>>>
>>
>> Moving to GitHub should be an excellent occasion to revisit how the CLA
>> works and provide better integration, e.g.: by using something like
>> CLAHub[1].
>>
>
> FYI we're looking at CLAHub as a possible solution for this (either
> directly or with a few modifications to tie it into our systems). No
> promises but it's on the table.
>
>  That's why we're proposing to ditch per-WG anything here. The way
>>> html-testsuite is set up, we already have subdirectories for html,
>>> canvas2d, and microdata. Those are all from the HTML WG, but they're
>>> just listed as the individual specs. We can keep on adding more specs in
>>> there (the Web Crypto people are looking to do that).
>>>
>>
>> That sounds good to me. It's the per WG siloing I'm opposed to, not the
>> one repository to rule them all idea.
>>
>
> Good! Well, it looks like everyone agrees... If we're forging ahead, I
> have admin rights to the repo so you know who to prod.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>

Declarative invocation and progressing Web Intents

[Frederick.Hirsch]

Fred

I object to this being a resolution, since I never saw a formal "Call for 
Consensus" sent to the WebIntents list.  I saw an informal discussion of ideas 
and an offer to provide proposals, not a proposal to change where standards are 
delivered. I know the DAP WG has not had a chance to discuss or agree to this 
resolution.

In addition, currently members of DAP have work items to progress both  Web 
Intents  and Web Activities and we have not stopped this work - though we need 
to review the status.

I also am not clear on the IPR implications of work being done in the PUA CG 
versus/with a working group.

I suggest a change to what you propose. I would like to suggest that the PUA CG 
consider Declarative Invocation in cooperation with the WebIntents Task Force, 
and provide input  regarding Web Intents development, but not take over 
development of this standardization.  I suggest the standard remain a joint 
deliverable from DAP (and WebApps)  WGs as joint deliverables until we formally 
decide otherwise.

I think first steps for declarative invocation, however, might be documenting 
use cases and requirements.

What do others think?

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group





On Jan 21, 2013, at 7:15 PM, ext Fred Andrews wrote:

Given that there have been no objections, the PUA CG accepts the development of 
the 'Declarative Invocation' standard.  This technology has great potential for 
securing the users private UA state and is well aligned with the charter of the 
PUA CG.

Given that this will likely require a rewrite of the Web Intents proposal the 
PUA CG will also take over the development of a suitable replacement.  Members 
of the Web Intents Task Force are invited to join the PUA CG for further 
discussions.

cheer
Fred

Chair
Private User Agent Community Group


From: freda...@live.com
To: jhawk...@google.com
CC: public-web-inte...@w3.org; 
public-...@w3.org
Date: Wed, 9 Jan 2013 03:19:31 +
Subject: RE: Declarative invocation

Dear James,

The declarative invocation markup would ideally support multiple inputs from a 
webpage and multiple outputs back to the webpage.  There might be multiple 
intents supported on a page, and perhaps there might even be overlap between 
the inputs and outputs.

For example, a file input element could declare the mime type(s) accepted, and 
this could be used with a pick intent to return a blob (single output).  This 
blob might be then be usable as a further input to an 'image edit' intent that 
returns an updated blob (single input, single output).  Finally when the input 
form is submitted the blob is sent.  This could allow a webpage without JS 
enabled to upload an edited image captured from a device camera, all from 
within the web browser.  The user can use trusted web apps for the image 
capture and for the image editing without exposing the camera API and without 
sharing UA state via an image editing web app.

For example, a section of an input form with contact inputs (name, address, 
etc), could be used with an intent that can search a trusted 'contacts' web app 
using supplied fields to direct the search and returning the requested fields 
that are used to populate the input form (multiple input, multiple output).  
The user might make some changes to the address and invoke another web intent 
to save the new contact address (multiple input, no output?).

There may be some opportunity to coordinate the required markup with general 
'semantic web' markup, such a microdata.  The web browser could then implement 
the UI and invocation without the webpage needing to add the UI support, and 
this might be done in a manner that is less vulnerable to spoofing.  I would 
also be keen to explore how this could help accessibility of webpage input 
forms.

For example, a photo viewing webpage might markup a slideshow allowing a 
presentation web app, that is specifically adapted to a limited device, to show 
the slide show and this could be invoked via a web intent (multiple input, no 
output).

The direction to take with the webpage UI support for invoking web intents is 
not clear to me yet.  It would be good to support buttons that can invoke an 
intent, such as a 'share' intent button, and this would allow a webpage to 
voluntarily place and style invocation buttons.  Buttons might also by placed 
around form input elements, such as a text input form element.

Other options being explored are allowing a web app to take over an element or 
region of a webpage when invoked - for example could a web app invoked via web 
intents might take over a webpage text input form element within the page to 
offer a rich HTML editor.   Other options are to overlay a webpage region, or a 
popup?

Support is also needed for legacy webpages, without semantic markup and web 
i

Re: [IndexedDB] IDBKeyRange should have static functions

[Joshua Bell]

Very much appreciated. I've added this and the other 4 items from Ms2ger to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17649 for tracking purposes,
since there was some overlap with items in there already.


On Sun, Jan 20, 2013 at 11:57 PM, Ms2ger  wrote:

> Hi all,
>
> From the examples in the IDB specification (in [1], for example) and from
> existing implementations, it appears that the functions on the IDBKeyRange
> interface (only, lowerBound, upperBound and bound) should be static.
> However, there is no actual normative requirement to that effect; instead,
> the IDL snippet requires those functions to only be callable on IDBKeyRange
> instances. [2]
>
> If this is caused by a bug in ReSpec, I suggest that either ReSpec is
> fixed or the spec moves away from ReSpec to a tool that doesn't limit what
> can be specified. In any case, an insufficient tool can not be used as an
> excuse for an incorrect specification, and I doubt we could publish a Rec
> without this shortcoming being addressed.
>
> HTH
> Ms2ger
>
> [1] https://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/**
> Overview.html#key-generator-**concept
> [2] https://dvcs.w3.org/hg/**IndexedDB/raw-file/tip/**
> Overview.html#idl-def-**IDBKeyRange
>
>

Re: Proposal: moving tests to GitHub

[Robin Berjon]

On 22/01/2013 17:14 , Tobie Langel wrote:

On 1/22/13 4:45 PM, "Robin Berjon"  wrote:

You *do* need to make the proper commitments for the test suite, but
those are much lighter and can easily be extended to all.


Moving to GitHub should be an excellent occasion to revisit how the CLA
works and provide better integration, e.g.: by using something like
CLAHub[1].


FYI we're looking at CLAHub as a possible solution for this (either 
directly or with a few modifications to tie it into our systems). No 
promises but it's on the table.



That's why we're proposing to ditch per-WG anything here. The way
html-testsuite is set up, we already have subdirectories for html,
canvas2d, and microdata. Those are all from the HTML WG, but they're
just listed as the individual specs. We can keep on adding more specs in
there (the Web Crypto people are looking to do that).


That sounds good to me. It's the per WG siloing I'm opposed to, not the
one repository to rule them all idea.


Good! Well, it looks like everyone agrees... If we're forging ahead, I 
have admin rights to the repo so you know who to prod.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/22/13 4:45 PM, "Robin Berjon"  wrote:

>On 22/01/2013 14:48 , Tobie Langel wrote:
>> Yes, I guess what I want to avoid at all costs is the split per WG which
>> has boundaries that partially happen at IP level, rather than strictly
>>at
>> the technology level.
>
>My understanding is that we don't have to care about spec-IP issues in
>test suites because when you contribute to a test suite you're not
>contributing to the spec's essential claims.

That's correct.

>You *do* need to make the proper commitments for the test suite, but
>those are much lighter and can easily be extended to all.

Moving to GitHub should be an excellent occasion to revisit how the CLA
works and provide better integration, e.g.: by using something like
CLAHub[1].

>That's why we're proposing to ditch per-WG anything here. The way
>html-testsuite is set up, we already have subdirectories for html,
>canvas2d, and microdata. Those are all from the HTML WG, but they're
>just listed as the individual specs. We can keep on adding more specs in
>there (the Web Crypto people are looking to do that).

That sounds good to me. It's the per WG siloing I'm opposed to, not the
one repository to rule them all idea.

--tobie

---
[1]: https://github.com/jasonm/clahub

Re: Proposal: moving tests to GitHub

[Robin Berjon]

On 22/01/2013 14:48 , Tobie Langel wrote:

Yes, I guess what I want to avoid at all costs is the split per WG which
has boundaries that partially happen at IP level, rather than strictly at
the technology level.


My understanding is that we don't have to care about spec-IP issues in 
test suites because when you contribute to a test suite you're not 
contributing to the spec's essential claims.


You *do* need to make the proper commitments for the test suite, but 
those are much lighter and can easily be extended to all.



Whether we end up as:

 w3c-tests/
 deviceorienation/
 html5/
 pointerevents/
 progressevent/
 xmlhttprequest/

or:

 deviceorienation-tests/
 html5-tests/
 pointerevents-tests/
 progressevent-tests/
 xmlhttprequest-tests/

Doesn't really matter (though I do find the former more readable). What
bothers me however is how had to parse per-WG-organization is for
newcomers.


That's why we're proposing to ditch per-WG anything here. The way 
html-testsuite is set up, we already have subdirectories for html, 
canvas2d, and microdata. Those are all from the HTML WG, but they're 
just listed as the individual specs. We can keep on adding more specs in 
there (the Web Crypto people are looking to do that).


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: [File API] About Partial Blob Data, XHR and Streams API

[Cyril Concolato]

Hi Arun,

Le 22/01/2013 15:04, Arun Ranganathan a écrit :

Hi Cyril,


1) I'm wondering why in progressive mode, does the spec say: 
|"|partial Blob data is an |ArrayBuffer|[TypedArrays 
] object 
consisting of the bytes|loaded|so far". Why isn't it the bytes loaded 
since the previous progress event?


AR: It is always a new ArrayBuffer.  The phraseology "so far" could be 
replaced by "bytes loaded since the previous progress event" though 
I'm not always sure that will be the case.
I understood from Jonas' answer that it was a new ArrayBuffer. What 
remained unclear was the content of the ArrayBuffer: all the data from 
the beginning of the read operation (which was problematic), or only the 
data read since the previous progress event (which I prefer). If, as you 
say, this is latter option, then please fix the spec. as "so far" is 
very ambiguous.




In my use case, the binary data resource might have an infinite
size, in which case the result objects will grow forever.
I looked at the Streams API [1] to see if there was any difference
for that but I couldn't see any. Reading with the FileReader
interface a Stream (dynamic length) or a Blob (fixed length) seems
to always return the whole content.


AR: Here, do you mean, you never get a progressevent other than load 
and loadend in your tests?

No, I meant that the Streams API uses the same approach as the File API:
"This method should mimic|FileReader.readAsArrayBuffer()| 
"
So, I understood reading "so far" that you would get the content of the 
stream read so far from the beginning at each time, which is practically 
unusable. If the FileAPI spec is fixed, the Streams API is fixed as well.


Certainly, if you had binary data of infinite size, you'll get  
several result objects.  The file API, particularly FileReader, 
shouldn't be used in streaming scenarios.
I disagree. The File API combined with XHR should be fine for reading 
(large) files for which the size is known when making the request but 
still delivered using HTTP streaming approaches. The Streams API and XHR 
should be fine for the same thing but for (infinite) files for which you 
don't know the size (chunked transfer to simulate IceCast/ShoutCast). A 
possible problem is when the apps want to receive the exact chunks 
created by the server (point 2 in my previous email) which the 
FileReader API doesn't preserve.


Cyril

--
Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
http://concolato.wp.mines-telecom.fr/

Re: [File API] About Partial Blob Data, XHR and Streams API

[Arun Ranganathan]

Hi Cyril, 

1) I'm wondering why in progressive mode, does the spec say: " partial Blob 
data is an ArrayBuffer [ TypedArrays ] object consisting of the bytes loaded so 
far ". Why isn't it the bytes loaded since the previous progress event? 

AR: It is always a new ArrayBuffer. The phraseology "so far" could be replaced 
by "bytes loaded since the previous progress event" though I'm not always sure 
that will be the case. 

> In my use case, the binary data resource might have an infinite size,
> in which case the result objects will grow forever.
> I looked at the Streams API [1] to see if there was any difference
> for that but I couldn't see any. Reading with the FileReader
> interface a Stream (dynamic length) or a Blob (fixed length) seems
> to always return the whole content.
AR: Here, do you mean, you never get a progressevent other than load and 
loadend in your tests? Certainly, if you had binary data of infinite size, 
you'll get  several result objects. The file API, particularly 
FileReader, shouldn't be used in streaming scenarios. 

-- A* 

Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/22/13 2:23 PM, "Robin Berjon"  wrote:

>On 22/01/2013 13:27 , Odin Hørthe Omdal wrote:
>> I'm not really sure if that is needed. If we can trust someone in one
>> repository, why not in all?
>
>I'd add to that: the odds are that if someone is screwing things up,
>it's better to have more eyes on what they're doing.
>
>> But what wins me over, is really the overhead question. Do anyone really
>> want to manage lots of repositories?  And for what reason?  Also, we
>> want more reviewers.  If I'm already added for CORS, I could help out
>> for say XMLHttpRequest if there's a submission/pull request languishing
>> there.
>
>I think Odin makes convincing arguments. For me it's really the outreach
>argument. Just one repo, carrying its one setup and one set of docs, can
>easily be pitched as the One True Place to Save The Web. It's a lot
>easier to explain at a conference or such: just go there, and patch stuff.

Yes, I guess what I want to avoid at all costs is the split per WG which
has boundaries that partially happen at IP level, rather than strictly at
the technology level.

Whether we end up as:

w3c-tests/
deviceorienation/
html5/
pointerevents/
progressevent/
xmlhttprequest/

or: 

deviceorienation-tests/
html5-tests/
pointerevents-tests/
progressevent-tests/
xmlhttprequest-tests/

Doesn't really matter (though I do find the former more readable). What
bothers me however is how had to parse per-WG-organization is for
newcomers.

--tobie

Re: Proposal: moving tests to GitHub

[Robin Berjon]

On 22/01/2013 13:27 , Odin Hørthe Omdal wrote:

I'm not really sure if that is needed. If we can trust someone in one
repository, why not in all?


I'd add to that: the odds are that if someone is screwing things up, 
it's better to have more eyes on what they're doing.



But what wins me over, is really the overhead question. Do anyone really
want to manage lots of repositories?  And for what reason?  Also, we
want more reviewers.  If I'm already added for CORS, I could help out
for say XMLHttpRequest if there's a submission/pull request languishing
there.


I think Odin makes convincing arguments. For me it's really the outreach 
argument. Just one repo, carrying its one setup and one set of docs, can 
easily be pitched as the One True Place to Save The Web. It's a lot 
easier to explain at a conference or such: just go there, and patch stuff.



Anyway, for my part, the how-to-split repository issue is not that
important compared to having the tests at GitHub in the first place :-)


Agreed. But how about we start with just one repo and then split them 
into several if it's a problem?


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Proposal: moving tests to GitHub

[Odin Hørthe Omdal]

Tobie Langel wrote:

Odin wrote:
Ms2ger proposed merging our repository with HTML at the same time and  
not

necessarily having one repository for each group. I was already thinking
such a move might be beneficial to do for webapps and webappsec, but it
might be even more simple to also have html testsuite in that merge.


There are benefits to both approaches. I would be in favor of having a
repository per spec (named tr_shortname-testsuite). This will make it a
lot easier to securely give scoped commit rights to external contributors
when the need arises.


I'm not really sure if that is needed. If we can trust someone in one  
repository, why not in all?


Having one repository also makes that one more visible, and if you already  
have a checkout for fixing CORS tests, and then suddenly encounter an SSE  
error, you can easily write that test in the checkout you already have.  I  
think the best people we can optimize for is the people who have already  
written some tests.  If it's easy for them to spread out, then we'll get  
more tests.


The visibility might also help, person X forks the test repo in order to  
fix a test in Microdata.  Any linking or talking she'll do about that fix  
will point people to that repo.  If people are like me, they might  
normally poke around a bit in the tree and suddenly they'll also know  
where the tests for e.g. XMLHttpRequest is at.



But what wins me over, is really the overhead question. Do anyone really  
want to manage lots of repositories?  And for what reason?  Also, we want  
more reviewers.  If I'm already added for CORS, I could help out for say  
XMLHttpRequest if there's a submission/pull request languishing there.


Anyway, for my part, the how-to-split repository issue is not that  
important compared to having the tests at GitHub in the first place :-)


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/22/13 12:37 PM, "Anne van Kesteren"  wrote:

>On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel  wrote:
>> That's definitely something to keep in mind. How frequent is it that a
>> feature moves from one spec to another (that, is outside of the
>>continuous
>> flow of features that migrate from HTML5 to WebApps)?
>>
>> Is your concern about history loss?
>
>My concern is 1) make work and 2) overhead of deciding what has to be
>tested where.

Figuring out precisely what it is you are trying to test is the crux of
the work. Having a repository per specification lightens the cognitive
load, not burdens it more. Especially for external contributors which
might not be aware of which WG handles what specs.

>E.g. tests for the ProgressEvent interface test quite a
>bit of IDL related requirements, where do they go?

Well, in that case[1], it seems the decision to put it under the
ProgressEvent directory has already been made. I don't see how this folder
being the root of a git repository or a subfolder is relevant.

With regards to the specifics of WebIDL requirements testing, there's work
going on to parse WebIDL and generate assertions out of it. Where that
isn't sufficient it seems a set of dedicated assertions (added to
testharness.js) would greatly simplify testing and answering the question
as to where these should go.

>From a distance it
>might all appear modular, but it really is all quite interconnected
>and by creating artificial boundaries that interconnectedness might
>not get testing.

These boundaries are created at the spec level. I see no harm in
replicating them at the test level. And there's certainly nothing
artificial in doing so.

That said, I agree integration testing is key, but it should be done
explicitly and methodically, not by relying on accidental coverage that's
hard to measure. The fun part about integration testing is it actually
tests the specs more than it tests the implementations themselves.

--tobie
 
---
[1]: http://w3c-test.org/webapps/ProgressEvents/tests/submissions/

Re: Proposal: moving tests to GitHub

[James Graham]

On 01/22/2013 12:37 PM, Anne van Kesteren wrote:

On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel  wrote:

That's definitely something to keep in mind. How frequent is it that a
feature moves from one spec to another (that, is outside of the continuous
flow of features that migrate from HTML5 to WebApps)?

Is your concern about history loss?


My concern is 1) make work and 2) overhead of deciding what has to be
tested where. E.g. tests for the ProgressEvent interface test quite a
bit of IDL related requirements, where do they go? From a distance it
might all appear modular, but it really is all quite interconnected
and by creating artificial boundaries that interconnectedness might
not get testing.


I don't have a strong opinion either way here, but I note that it is 
generally possible to move things between repos relatively easily 
without losing history e.g. using git subtree[1], so I don't think that 
it is necessary to make a decision on this before moving to git.


With that in mind, I suggest doing the move with the repository 
structure more or less as it is today and then later merging the repos 
if we decide that is desirable.


[1] https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

Re: Proposal: moving tests to GitHub

[Anne van Kesteren]

On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel  wrote:
> That's definitely something to keep in mind. How frequent is it that a
> feature moves from one spec to another (that, is outside of the continuous
> flow of features that migrate from HTML5 to WebApps)?
>
> Is your concern about history loss?

My concern is 1) make work and 2) overhead of deciding what has to be
tested where. E.g. tests for the ProgressEvent interface test quite a
bit of IDL related requirements, where do they go? From a distance it
might all appear modular, but it really is all quite interconnected
and by creating artificial boundaries that interconnectedness might
not get testing.


-- 
http://annevankesteren.nl/

Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/22/13 12:20 PM, "Anne van Kesteren"  wrote:

>On Tue, Jan 22, 2013 at 12:11 PM, Tobie Langel  wrote:
>> There are benefits to both approaches. I would be in favor of having a
>> repository per spec (named tr_shortname-testsuite). This will make it a
>> lot easier to securely give scoped commit rights to external
>>contributors
>> when the need arises.
>
>Given how we relatively frequently move features around and have not
>exactly figured out the overall architecture I don't think that's an
>approach that scales.

That's definitely something to keep in mind. How frequent is it that a
feature moves from one spec to another (that, is outside of the continuous
flow of features that migrate from HTML5 to WebApps)?

Is your concern about history loss?

--tobie

Re: Proposal: moving tests to GitHub

[Anne van Kesteren]

On Tue, Jan 22, 2013 at 12:11 PM, Tobie Langel  wrote:
> There are benefits to both approaches. I would be in favor of having a
> repository per spec (named tr_shortname-testsuite). This will make it a
> lot easier to securely give scoped commit rights to external contributors
> when the need arises.

Given how we relatively frequently move features around and have not
exactly figured out the overall architecture I don't think that's an
approach that scales.


-- 
http://annevankesteren.nl/

Re: Proposal: moving tests to GitHub

[Tobie Langel]

On 1/22/13 11:53 AM, "Odin Hørthe Omdal"  wrote:

>Hi!
>
>   We just had a small discussion on webapps-testsuite [1] about the
>possibility of moving the webapps tests.  I was wrongly under the
>impression that we had discussed this before (hey, confusion is not a
>crime ;) ).

We had such a discussion in testing a while back.[a]

>Now that HTML has done the move, I think it is time for us to
>look at it too.  Ms2ger and Robin, which did most of the HTML testsuite
>[2] move were happy to help [3].
>
>Ms2ger proposed merging our repository with HTML at the same time and not
> 
>necessarily having one repository for each group.  I was already thinking
> 
>such a move might be beneficial to do for webapps and webappsec, but it
>might be even more simple to also have html testsuite in that merge.

There are benefits to both approaches. I would be in favor of having a
repository per spec (named tr_shortname-testsuite). This will make it a
lot easier to securely give scoped commit rights to external contributors
when the need arises.

>Robin wrote an email describing what they did for the HTML move, some of
>which should be relevant for our potential move too [4].  Of particular
>interest the possibility for having tests in folders by section of the
>spec, and making submissions pull requests.
>
>
>I'm interested in such a move because it'll make our tests more visible,
>and easier to contribute to.  Just this weekend the Server Sent Events
>spec got 6 pull requests from a GitHub user "Yaffle" [5].  Note that that
> 
>particular repository will be moved into however our new test repository
>structure will be, so it probably won't remain as a separate repository.

More thoughts here:
http://tobie.github.com/w3c-testing-plan/unofficial-w3c-testing-plan-201201
16.html#transition-test-repositories-to-github

--tobie

---
[a]: 
http://lists.w3.org/Archives/Public/public-test-infra/2012JulSep/0027.html

Re: Proposal: moving tests to GitHub

[Florian Bösch]

I think it's a good idea. The WebGL specification/tests moved to github
which made contributing patches (as pull requests) a lot easier.


On Tue, Jan 22, 2013 at 11:53 AM, Odin Hørthe Omdal wrote:

> Hi!
>
>   We just had a small discussion on webapps-testsuite [1] about the
> possibility of moving the webapps tests.  I was wrongly under the
> impression that we had discussed this before (hey, confusion is not a crime
> ;) ).  Now that HTML has done the move, I think it is time for us to look
> at it too.  Ms2ger and Robin, which did most of the HTML testsuite [2] move
> were happy to help [3].
>
> Ms2ger proposed merging our repository with HTML at the same time and not
> necessarily having one repository for each group.  I was already thinking
> such a move might be beneficial to do for webapps and webappsec, but it
> might be even more simple to also have html testsuite in that merge.
>
> Robin wrote an email describing what they did for the HTML move, some of
> which should be relevant for our potential move too [4].  Of particular
> interest the possibility for having tests in folders by section of the
> spec, and making submissions pull requests.
>
>
> I'm interested in such a move because it'll make our tests more visible,
> and easier to contribute to.  Just this weekend the Server Sent Events spec
> got 6 pull requests from a GitHub user "Yaffle" [5].  Note that that
> particular repository will be moved into however our new test repository
> structure will be, so it probably won't remain as a separate repository.
>
>
> [1] http://lists.w3.org/Archives/**Public/public-webapps-**
> testsuite/2013Jan/0019.html
> [2] 
> https://github.com/w3c/html-**testsuite
> [3] http://lists.w3.org/Archives/**Public/public-webapps-**
> testsuite/2013Jan/0022.html
> [4] http://lists.w3.org/Archives/**Public/public-webapps-**
> testsuite/2013Jan/0024.html
> [5] 
> https://github.com/w3c/event-**source/pulls
>
> --
> Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software,
> http://opera.com
>
>

Proposal: moving tests to GitHub

[Odin Hørthe Omdal]

Hi!

  We just had a small discussion on webapps-testsuite [1] about the  
possibility of moving the webapps tests.  I was wrongly under the  
impression that we had discussed this before (hey, confusion is not a  
crime ;) ).  Now that HTML has done the move, I think it is time for us to  
look at it too.  Ms2ger and Robin, which did most of the HTML testsuite  
[2] move were happy to help [3].


Ms2ger proposed merging our repository with HTML at the same time and not  
necessarily having one repository for each group.  I was already thinking  
such a move might be beneficial to do for webapps and webappsec, but it  
might be even more simple to also have html testsuite in that merge.


Robin wrote an email describing what they did for the HTML move, some of  
which should be relevant for our potential move too [4].  Of particular  
interest the possibility for having tests in folders by section of the  
spec, and making submissions pull requests.



I'm interested in such a move because it'll make our tests more visible,  
and easier to contribute to.  Just this weekend the Server Sent Events  
spec got 6 pull requests from a GitHub user "Yaffle" [5].  Note that that  
particular repository will be moved into however our new test repository  
structure will be, so it probably won't remain as a separate repository.



[1]  
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0019.html

[2] https://github.com/w3c/html-testsuite
[3]  
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0022.html
[4]  
http://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0024.html

[5] https://github.com/w3c/event-source/pulls

--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com