IRC log of htmlt on 2012-12-04

Timestamps are in UTC.

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