15:46:29 RRSAgent has joined #htmlt 15:46:29 logging to http://www.w3.org/2012/12/04-htmlt-irc 16:02:55 plh has joined #htmlt 16:03:21 OK 16:04:02 We have been starting a few minutes late in case people show up a bit late...like you plh :) 16:06:34 back 16:07:31 Ok then lets get started! 16:08:10 Like many past meeting we'll do this on IRC - especially since I have a very bad cough from a cold I'm trying to get over... 16:08:36 sorry to hear about your cough, yes, irc is fine 16:09:30 I sent an agenda out to the list see http://lists.w3.org/Archives/Public/public-html-testsuite/2012Dec/0000.html 16:10:03 yep, I'm curious about the status of the test organization 16:10:12 I was hoping we could continue the discussion about the test repository organization 16:10:42 The last meeting was 1:30+ minutes :) 16:11:01 plh take a peek at the IRC from the last meeting... 16:11:13 ok 16:11:13 IRC -> http://www.w3.org/2012/11/20-htmlt-irc 16:11:34 James did you have any thoughts after the meeting? 16:13:02 I still need to do some testing/investigation with branching and Hg 16:14:27 Plh the high level view is that we will basically be creating 'short machine readable names' for each heading in the HTML5 table of contents 16:15:06 I can help with that if needed 16:15:08 This would allow us to move tests into each 'heading' without the need for adding meta data to every test. 16:15:26 I already have phantomjs scripts to extract the TOC 16:15:45 This should also help provide some coverage data on the specification. 16:15:53 agreed 16:16:01 It won't be perfect but will be better than what we have today... 16:17:44 will it based on the section ID or the section title? 16:18:00 Let me type in an example... 16:20:56 For example the table of contents... 16:21:15 Has a chapter called '2 Common infrastructure' 16:21:49 We would have a folder in HG /html5/common_infrastructure/ 16:21:54 plh: I think using title is better because the ids are autogenerated and not very easy to find 16:22:11 ok, so based on title 16:22:34 do we keep the hierarchy as well? 16:22:37 Now we would also have 'sub folders' 16:22:57 Such that a test for 2.4 UTF-8 would be placed in... 16:23:24 html5 common_infrastructure utf-8 16:23:33 IRC has a bug that it eats '/' 16:24:07 so you have to put a '/' in the spaces after, html5, common_infrastructure and utf-8 :) 16:24:11 don't use '/' as the first character, put a space before. that should do the trick 16:24:20 /html5/common_infrastructure/utf-8/ 16:24:23 Ah ha!! 16:24:25 /html5/common_infrastructure/utf-8 16:25:03 now, how to we deal between html5 and html5.1 ? 16:25:09 s/to/do/ 16:25:11 That is a great question! 16:25:32 s/great/hard/ 16:26:05 I could ask first if you prefer: how do we deal between submitted and approved? (if we keep those concepts) 16:26:10 I think we should have branches... 16:26:23 ...For submitted and approved and for HTML5.1 16:26:55 I can imagine using branches for html5 and html5.1, but it seems difficult for submitted and approved 16:27:07 Well 16:27:13 It depends (TM) 16:27:33 right now, we have to copy a bunch of files from one directory to another 16:27:36 A branch for submitted and a branch for approved is craziness 16:27:40 But 16:28:01 A branch (aka pull request) per submission seems reasonable 16:28:12 and integrates well with code review tools 16:28:26 ah, I understand 16:28:38 that seems better indeed 16:29:30 I open as long as it's clear that we have a distinction to known good tests compared to test that someone just wrote and submitted. 16:29:57 so, if I want to submit 20 tests, would I do one pull request those 20? 16:30:18 what if one of them is approved? does it hold the other 19? 16:30:29 s/is approved/isn't approved/ 16:30:55 Then you would need to add a patch to remove the broken test before merging the branch 16:31:56 ok 16:32:32 I *think* you could also do a pull request from 'canvas2' to html5 16:33:10 I still need to do some investigation... 16:33:22 but I think this would work better overall 16:33:53 speaking of canvas2d vs html5, will we have one single repository for all the html specs or separate ones? 16:34:28 My view is that we just need clear spots for each... 16:34:50 so that we don't mix Canvas2 tests with the main html5 test suite 16:35:15 if it's one single, then we'll have directories for html/ , canvas2d/, microdata/ 16:36:02 I'm less conserner about canvas2d and microdata 16:36:14 s/conserner/conserned/ 16:36:30 then let's keep them in one single repository with different directories 16:36:52 More conserned with putting encrypted media or any of the HTML.Next feature/tests under the html5 folder 16:37:26 if we have different branches, that should be ok, right? 16:37:32 Does that make sense plh? 16:38:27 * cough, cough 16:38:31 if we have html5 and html5.1 in the same folders but different branches, I think we should name the directory html/ 16:39:27 and folks would do pull request against one of the branches 16:40:03 So then we would have http://www.w3c-test.org/html/html5 and http://www.w3c-test.org/html/html5.1/? 16:40:25 yes, we could actually 16:40:48 we'll pull the branches separately on w3c-test.org 16:41:20 cool 16:41:44 that's what they're doing for the html spec actually 16:42:17 I still need to think about this a bit more but I think this will help improve and solve some of the problems we are facing 16:43:06 ..and make it so that we are setup for the future 16:43:26 did you guys consider an other approach for submitted/approved: we have everything into the same directory and approvedtests.txt only list the ones that have been approved? 16:43:28 plh can you talk with some other people at the w3c and get their thoughts? 16:43:46 yes, Robin would be perfect for that 16:43:47 Since this may create some work, for example the hg -> web server proping.. 16:43:53 unfortunately, he is away at the moment 16:44:26 The approvedtests thing would work 16:44:37 he is busy on the drafts those days but helping the restructure of the test suite is next on his list after that 16:44:46 But we want to encourage branch-per-submission anyway, I think 16:45:41 jgraham can you put into IRC how a branch-per-submission would work? 16:46:30 I'll tell Robin to look at the logs and provide his opinion 16:47:14 the sooner we can get this done and reorganized, the better imho 16:47:35 Yes, I'd like to close here before the x-mas break 16:50:02 Though part of this will need alot more documentation on the wiki! 16:50:11 agreed 16:52:30 James, re: code review tools, should we recommend one or several of them to folks to use? 16:53:04 Opera said they have one the w3c could use at TPAC 16:53:10 krisk: Well, with hg, I'm not quite sure. With git you write your tests on a local branch say classList. Then when you are done you git push w3c classList:opera/classList 16:53:29 https://github.com/jensl/critic 16:53:34 Then you mail the list and say "please review my tests on the opera/classList" branch 16:53:40 Right 16:53:44 So, code review 16:53:56 We should have exactly one code review tool that we choose 16:54:04 For this model critic is ideal I think 16:54:12 But I am somewhat biased 16:54:36 So in that case you do git push critic classList:r/opera/classList 16:54:50 (the "critic" remote could just be the "w3c" remote) 16:54:58 And it automatically creates a review 16:55:16 Which allows anyone with an account to comment on your submission 16:55:29 so, is that something that needs to be set up on the hg server? 16:55:36 and if they find issues you keep pushing new commits to the same branch 16:55:39 Until it is accepted 16:55:47 Well, critic does work with hg, only git 16:55:56 does, or doesn't ? 16:56:01 *doesn't 16:56:20 One coudl maybe try with some hg-git conversion layer 16:56:29 would it work if we were using github? 16:56:34 Yes 16:56:53 It needs a little extra code so that a pull request becomes a review request 16:57:12 but I guess that's easy to deploy on github, right? 16:57:14 But I'm sure that is possible (and sort of told jl I would write it) 16:57:34 Yes 16:57:43 You still need a server to host critic itself 16:57:57 But it is possible to integrate it with github in a nice way 16:58:51 Kris, did you give any thoughts on facilitating code review? 16:59:21 This might help people get and idea of how this could work 16:59:23 http://blog.jdhardy.ca/2010/11/developing-ironpython-with-mercurial.html 16:59:42 Not the bitbucket part :) 17:00:38 See the section about 'Working With a Bitbucket Fork' 17:01:44 We'll OK - how about we meet again next tuesday same time, etc? 17:01:54 Yup 17:03:08 sungok_you has joined #htmlt 17:04:14 Let's adjourn 17:04:31 RRSAgent, make logs public 17:09:43 Ms2ger has joined #HTMLT