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