Proposal: moving tests to GitHub
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
Re: Proposal: moving tests to GitHub
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 odi...@opera.comwrote: 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.htmlhttp://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0019.html [2] https://github.com/w3c/html-**testsuitehttps://github.com/w3c/html-testsuite [3] http://lists.w3.org/Archives/**Public/public-webapps-** testsuite/2013Jan/0022.htmlhttp://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0022.html [4] http://lists.w3.org/Archives/**Public/public-webapps-** testsuite/2013Jan/0024.htmlhttp://lists.w3.org/Archives/Public/public-webapps-testsuite/2013Jan/0024.html [5] https://github.com/w3c/event-**source/pullshttps://github.com/w3c/event-source/pulls -- Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Re: Proposal: moving tests to GitHub
On 1/22/13 11:53 AM, Odin Hørthe Omdal odi...@opera.com 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
On Tue, Jan 22, 2013 at 12:11 PM, Tobie Langel to...@fb.com 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
On 1/22/13 12:20 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 22, 2013 at 12:11 PM, Tobie Langel to...@fb.com 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
On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel to...@fb.com 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
On 01/22/2013 12:37 PM, Anne van Kesteren wrote: On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel to...@fb.com 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
On 1/22/13 12:37 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Jan 22, 2013 at 12:30 PM, Tobie Langel to...@fb.com 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
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
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
On 1/22/13 2:23 PM, Robin Berjon ro...@w3.org 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: [File API] About Partial Blob Data, XHR and Streams API
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: [File API] About Partial Blob Data, XHR and Streams API
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 http://dev.w3.org/2006/webapi/FileAPI/#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()| http://dev.w3.org/2006/webapi/FileAPI/#readAsArrayBufferSyncSection 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: Proposal: moving tests to GitHub
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: Proposal: moving tests to GitHub
On 1/22/13 4:45 PM, Robin Berjon ro...@w3.org 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
On 22/01/2013 17:14 , Tobie Langel wrote: On 1/22/13 4:45 PM, Robin Berjon ro...@w3.org 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: [IndexedDB] IDBKeyRange should have static functions
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 ms2...@gmail.com 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-**concepthttps://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-**IDBKeyRangehttps://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#idl-def-IDBKeyRange
Declarative invocation and progressing Web Intents
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.commailto:freda...@live.com To: jhawk...@google.commailto:jhawk...@google.com CC: public-web-inte...@w3.orgmailto:public-web-inte...@w3.org; public-...@w3.orgmailto: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 intents
Re: Proposal: moving tests to GitHub
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 ro...@w3.org 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
On 1/23/13 12:48 AM, Julian Aubourg j...@ubourg.net 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
