RE: HTML Testing Task Force Conf Call Agenda 12/11/2012

Meeting Notes

We reached consensus to use IDs for the folder names rather than the table of content section names.
For example the table of content '1 Introduction' section maps to http://www.w3.org/TR/html5/introduction.html#introduction in the specification.
The folder name would be introduction (text after the # with some char replacements (space -> '_').
We will start with three section names deep and if needed will add more folder sections.
	
We'll plan on meeting again next Tuesday to continue the discussion.

IRC Log
[07:58] == krisk [~krisk@public.irc.w3.org] has joined #HTMLT
[08:00] <krisk> reading all the list from last night....
[08:04] <jgraham> darobin: Excellent
[08:07] <krisk> all done reading the list...darobin ping IRC when you are back
[08:13] <darobin> back!
[08:14] <krisk> Ok let's get rolling...
[08:14] <krisk> Let's start with the directory organization
[08:15] <darobin> I like the one I proposed with the change to fold 5+5.1 and 2d+2d2 into just one dir for each
[08:15] <krisk> does anyone object with using IDs (e.g. #dom) vs the section name (Semantics, structure, and APIs of HTML documents )
[08:16] <darobin> (not me)
[08:16] <krisk> The reason I'm asking is that at the last meeting it was noted that the IDs change?
[08:16] <Ms2ger> The IDs mainly change if the section name changes
[08:16] <darobin> if the IDs change so will the section names...
[08:17] <Ms2ger> "dom" in particular seems pretty unspecific, but otherwise fine with me
[08:17] <krisk> I'm fine with the IDs (this is what I initially proposed :))
[08:17] <darobin> well, it's "dom" inside "html" so I reckon there's enough context
[08:18] <darobin> krisk: have you tried checking out the repo on windows? (or someone else?)
[08:18] <krisk> jgraham are you OK with IDs vs section names?
[08:18] <darobin> I don't have git setup on my VM, and frankly I'd rather avoid the hassle
[08:18] <darobin> e.g. some are called "document.write()"
[08:19] <darobin> or "the-h1,-h2,-h3,-h4,-h5,-and-h6-elements"
[08:19] <krisk> At the last meeting we agreed to use some simple names for sections so that they don't end up getting URL encoded or have file system conflicts.
[08:19] <darobin> I can escape more
[08:20] <krisk> For example not a good idea to use caps, replace space with a _
[08:20] <darobin> (it's just that the less escaping there is, the easier it is to map back to the spec)
[08:20] <krisk> Though I'm fine with using IDs
[08:20] <darobin> Anolis guarantees there won't be spaces and it's all lowercase
[08:20] <krisk> ...and this like you said makes it easy to map to the section in the spec
[08:20] <jgraham> Well I am not super-happy with IDs
[08:20] <jgraham> But I don't really object either
[08:21] <krisk> That I why I asked...
[08:21] <darobin> jgraham: you know that using the ID you can go to any-page-in-the-spec.html#that-ID and will get redirected to the right location?
[08:21] <krisk> are you less happy with simple section names?\
[08:21] <jgraham> At this point I think that robin having done the work acounts for quite a lot
[08:21] <jgraham> *counts
[08:22] <darobin> yeah, it's, like, 50 lines of JS so I should really get to decide
[08:22] <jgraham> Well if you did it in JS I take it all back; you're insane and should have no decision making power :p
[08:22] <darobin> :)
[08:23] <jgraham> But yeah IDs are good enough. I suppose we can make it easy enough to find the right id in the spec
[08:23] <darobin> do people want me to escape more than I already do?
[08:24] <Ms2ger> Turning everything outside [a-zA-Z0-9] into - is fine with me too
[08:24] <darobin> at a quick eyeballing I see "," "(" and ")" as potential candidates
[08:24] <darobin> I don't have a strong opinion
[08:25] <krisk> I agree with ms2ger - turn everything outside [a-zA-Z0-9] into -
[08:25] <darobin> of those, only comma seems to get encoded to %2C
[08:25] <darobin> fine, that wfm
[08:25] <Ms2ger> Are there any capitals, actually?
[08:26] <darobin> nope
[08:26] <krisk> we don't want caps, for sure it will cause pain...
[08:26] <darobin> as I said, Anolis does that for us
[08:26] <darobin> or at least, it really should
[08:26] <gsnedders> It does.
[08:28] <krisk> The other part is how deep the directory structure goes, proposal is two deep
[08:29] <Ms2ger> Three, I thought?
[08:29] <darobin> I went with three
[08:29] <krisk>   / dom / elements / semantics-0  
[08:29] <darobin> yeah, that's three :)
[08:29] <darobin> classic hacker disagreement
[08:29] <Ms2ger> That gives you one per element, which seems useful
[08:29] <darobin> yes
[08:29] <krisk>  / dom / elements / global-attributes /
[08:30] <jgraham> There is nothing that says this has to be a constant throughout the spec
[08:30] <krisk> ...which means we won have a specific folder for the-id-attribute
[08:30] <darobin> any fewer than three and you end up with huge amounts of stuff under /semantics/forms for instance
[08:30] <jgraham> If it makes sense to go deeper in some places and shallower in others that should work
[08:31] <darobin> we can go with three as the baseline and let people dig deeper at their own discretion
[08:31] <krisk> How about we just start with three (/ dom / elements / global-attributes /) and if someone needs deeper we can add them
[08:31] <Ms2ger> Do we need one for the ID attribute? :)
[08:31] <Ms2ger> Sounds good
[08:31] <darobin> wfm
[08:33] <darobin> are we all good on structure?
[08:33] <krisk> one oddity is that the top level folder structure ends up in an odd order when the web server alphabatizes the IDs
[08:34] <Ms2ger> *shrug*
[08:35] <darobin> krisk: I don't think that's a very big deal
[08:35] <darobin> the alternative is using numbers, and that will break as soon as someone adds a section
[08:35] <krisk> If we put a number on the front then this well get fixed (e.g. introduction -> 1.introduction)
[08:35] <krisk> Just at the top level...
[08:35] <darobin> if we want to present stuff in spec order it's trivial to just reuse the data from the spec :)
[08:35] <Ms2ger> That's a lot of moving when someone adds a section
[08:35] <jgraham> darobin: Maye it like basic: 10:introduction; 20:GOTO 10
[08:36] <Ms2ger> And what if a section is in 5.1 and not 5?
[08:36] <darobin> jgraham: you're joking but there was a voice in my head telling me to do that :)
[08:36] <jgraham> FWIW I think we can fix it for display if we need to
[08:36] <darobin> yeah Ms2ger makes the killer argument there - if we have branches with difference directory names it's going to be hell
[08:36] <darobin> it's very easy to fix for display
[08:37] <darobin> *very* easy
[08:37] <krisk> then let's not get too conserned with the order
[08:37] <darobin> the data that generated this structure actually has that information already
[08:38] <krisk> If enough people complain we can address this with HTML!
[08:38] <Ms2ger> darobin, is that data we need to keep up to date manually?
[08:38] <darobin> Ms2ger: it's extracted from the spec, so no, unless you count editing the spec
[08:39] <krisk> If the spec has massive changes then this or any other orgaization will fail...
[08:40] <krisk> A few years ago we went with the simplest manner -  feature names
[08:40] <krisk> and even then features got removed...
[08:40] <krisk> The IDs seem to be the best option at this time
[08:41] <krisk> assumption the the IDs should be rather concrete...though some section names are odd (embedded-content-0)
[08:41] <Ms2ger> Sounds like we're in violent agreement
[08:41] <darobin> Ms2ger: https://gist.github.com/4260155 is the code
[08:42] <Ms2ger> darobin, eww
[08:42] <darobin> (it won't be portable outside my computer as written, and it needs some changes to match newer decisions - but the basics are there)
[08:42] <darobin> Ms2ger: I know, JS in a Gist - everything you love wrapped up in one!
[08:43] <krisk> Ok then IDs and THREE sections deep to start!
[08:44] <krisk> Now lets move on to the top level names (HTML, HTML5, HTML51, CANVAS2D, etc...)
[08:44] <Ms2ger> No version numbers
[08:45] <darobin> +1
[08:46] <darobin> html, canvas, microdata directories; master and next branches
[08:47] <Ms2ger> Where master == whatwg, of course ;)
[08:47] <krisk> That is what I though we talked about at the last meeting
[08:47] <krisk> where master == w3c
[08:47] <darobin> Ms2ger: actually I was thinking master = 5.0, next = 5.1
[08:47] <darobin> whatwg is probably next plus a small delta
[08:48] <krisk> The problem we are trying to solve is...
[08:48] <Ms2ger> master should be the most current, IMO
[08:48] <krisk> A) don't have copies of the test suite (html5 and html51)
[08:48] <darobin> Ms2ger: I'm used to having master & develop, where develop is ahead of master
[08:48] <krisk> B) Make it clear where new features go (encrypted media, canvas.next)
[08:49] <Ms2ger> I'm used to trunk and branches
[08:49] <jgraham> I think I agree with Ms2ger
[08:49] <jgraham> I think we should have master and HTML5
[08:50] <darobin> ewww, an SVN user
[08:50] <Ms2ger> Also, I'm skeptical of branches :)
[08:50] <jgraham> Ms2ger: That's because you are skeptical of git :p
[08:50] <darobin> jgraham: I'd rather not actually - "HTML5" makes limited sense for canvas and stuff, and it will become the old old thing later on
[08:50] <Ms2ger> darobin, yes
[08:50] <darobin> we could have master and commander
[08:50] <Ms2ger> darobin, and the tests for it will become the old old thing too
[08:51] <Ms2ger> Which is why it shouldn't be master
[08:51] <jgraham> Exactly
[08:51] <darobin> more seriously, I recommend either A) master and next, if master is current 5.0, or B) master and stable, if master is current 5.1
[08:51] <jgraham> Well
[08:51] <Ms2ger> What if you get 5.0, 5.1 and 5.2?
[08:51] <jgraham> What do you expect to happen when 5.1 branches?
[08:51] <jgraham> Oh look
[08:51] <jgraham> there is no point in me typing anything
[08:52] <jgraham> Ms2ger always wins
[08:52] <Ms2ger> jgraham, that's because I use hg
[08:52] <darobin> Ms2ger: I expect that when that happens, 5.1 and 5.0 get merged, and we only care about the merged outcome plus 5.2
[08:52] <jgraham> Hmm, so you would basically delete the testsuite for HTML5
[08:52] <jgraham> For small values of "delete"
[08:52] <darobin> at that point, if you really need to keep a handle on what 5.0 once was, you use this crazy feature called "tags"
[08:53] <darobin> yeah, very small values
[08:53] <jgraham> Well
[08:53] <jgraham> I don't really see why your way is better
[08:53] <darobin> at some point you really stop caring about the Rec two versions back
[08:53] <darobin> because I came up with it?
[08:53] <jgraham> But I see that it might work
[08:53] <darobin> I want to keep the number of branches low and simple, over time
[08:53] <krisk> darobin: at some point you really stop caring about the Rec two versions back
[08:53] <Ms2ger> If you want CR test suites, I think you should keep them around
[08:54] <darobin> Ms2ger: tags
[08:54] <jgraham> I don't see why it matters if you have many branches vs many tags
[08:54] <krisk> darobin: I'm pretty sure CSS2.1 will be cared alot for a long time...float!
[08:54] <darobin> krisk: then let's not make the same mistakes the CSS WG did :)
[08:54] <darobin> hmmm, frankly though at this point I'm a bit lost as to what the various positions are
[08:54] <gsnedders> We need to make sure HTML5 v. HTML5.1 testsuites don't contain contradictions somehow. We can always take the CSS approach of removing tests. :)
[08:54] <gsnedders> darobin: position: top;
[08:55] <jgraham> Well
[08:55] <jgraham> I guess that is one advantage of darobin's scheme
[08:55] <darobin> what I said was "more seriously, I recommend either A) master and next, if master is current 5.0, or B) master and stable, if master is current 5.1" - are you objecting to both, or to my initial offer of using (A)?
[08:55] <jgraham> You can clearly say to people "we don't want you to use these older things"
[08:55] <jgraham> On the other hand
[08:56] <jgraham> Certain people/groups have the mistaken idea that what they really want is a HTMLX UA where X is some version that has a Rec.
[08:56] <Ms2ger> I definitely object to anything that sounds authoritative referring to the older one
[08:56] <jgraham> And they will try and take that testsuite, even if it contradicts newer specs and actual implementations
[08:57] <darobin> we could have "master" and "CR"
[08:57] <Ms2ger> wfm
[08:57] <jgraham> FWIW I think my position is that *right now* we clearly only need two branches
[08:57] <darobin> jgraham: on that we violently agree
[08:58] <darobin> master = whatever's most recent
[08:58] <krisk> Yes two branches...
[08:58] <darobin> CR = whatever's in CR right now
[08:58] <jgraham> and we can decide what to do if we ever get a 5.2 or whatever when that happens
[08:58] <darobin> which can change over time, but slow enough that even us cranky old fellas can adapt
[08:58] <jgraham> Depending on how well the system is working up to that point
[08:58] <darobin> yeah, let's cross that bridge when we get there
[08:58] <darobin> current timeline puts a CR for 5.2 in 2016
[08:59] <jgraham> Well we might all be dead by then
[08:59] <darobin> I'll be busy running for the 2017 presidential elections then, so whevs to the problems the next guy will have
[08:59] <darobin> so master and CR good for everyone?
[08:59] <Ms2ger> And I guess the HTMLWG will make HTML5 a rec before then, even if there's no interoperability to speak of
[08:59] <Ms2ger> So, sure
[08:59] <jgraham> Yes
[09:01] <krisk> I don't like the name - master
[09:01] <darobin> krisk: it's the name of the default branch in git
[09:01] <Ms2ger> master and slave, maybe :)
[09:01] <darobin> we can change it, there's nothing in git that says you have to have it
[09:01] <gsnedders> Ms2ger: A testsuite for masochists?
[09:01] <krisk> darobin did you take any history classes?
[09:01] <krisk> IMHO we should use names that map to the w3c process
[09:02] <krisk> E.g. draft and not master
[09:02] <Ms2ger> Everything is a fraft
[09:02] <darobin> I can live with ED and CR
[09:02] <Ms2ger> (Yeah, a fraft, shoot)
[09:02] <darobin> krisk: history classes? in high school
[09:03] <krisk> that seems to make a bit more sense...
[09:04] <krisk> so the ED branch woudl effectively contain everything (old and new)...
[09:04] <jgraham> Ugh
[09:04] <jgraham> Not having "master" in git is pretty unfriendly
[09:04] <krisk> s/woudl/would/
[09:05] <jgraham> It means we will be gratuitiously different from all the documentation
[09:05] <jgraham> So I am pretty against that. It's like not having "trunk" in SVN, or something
[09:06] <darobin> I can't say I feel strongly here
[09:06] <Ms2ger> Me neither
[09:06] <darobin> I've run master-less GH problems without a hitch
[09:06] <krisk> Well like it or not since we are actually increasing the complexity for test submissions we are going to have to create a bunch of docs on the w3c site
[09:06] <Ms2ger> Though if you're a git user, you've already chose the pain :)
[09:06] <jgraham> To be clear
[09:06] <darobin> e.g. ReSpec has no master branch (it uses gh-pages instead) and quite a few contributors - no one gets it wrong
[09:07] <jgraham> There isn't a *technical* issue
[09:07] <jgraham> The problem is that any new user will be confused
[09:07] <jgraham> I don't think that there is any value in creating that confusion
[09:07] <krisk> Well if we have some good documents on the w3c site on exactly what to so then it would require someone to go search the web
[09:08] <krisk> ..and then get confused with the 'master' name
[09:08] <krisk> ..change
[09:08] <jgraham> I dount that people will carefully read every bit of documentation we provide
[09:08] <jgraham> If they know it is git and get confused they are likely to look for a git tutorial
[09:09] <jgraham> *doubt
[09:09] <darobin> in general I don't think that we should rely on documentation, but I think that the confusion case is overstated here
[09:09] <gsnedders> Web developers used to git will get confused, a few W3C Process people will get confused. I think the latter is less important, as any git tutorial will help them which is where they will likely look.
[09:09] <krisk> we should just go with ED and CR
[09:09] <darobin> you clone the repo, there's no master, you look at the readme that says "Branches: ED for all cutting edge stuff, CR for what's in CR", you live to code another test
[09:09] <gsnedders> Everyone pretty much assumes a "master" branch as "trunk"
[09:10] <darobin> but, as I said, I don't think this matter either way
[09:10] <krisk> The other issue is that we are all so deep into git, svn, hg, trunk, etc...
[09:10] <jgraham> Even the git manpages assume "master"
[09:11] <krisk> to the outside world it's not clear what all these acronyms actually mean :)
[09:11] <jgraham> Right, but the point is to not make things harder
[09:11] <darobin> actually most of those aren't even acronyms :)
[09:12] <jgraham> People who have used git a little bit are used to the idea that there's a master branch which contains the latest state of the code
[09:12] <darobin> (in fact none are, which is confusing to people who expect that from computer lingo :)
[09:12] <krisk> I think the ED will make alot of sense - it's what is in the current editors draft
[09:12] <Ms2ger> Nah, it's what's in the LS
[09:12] <darobin> jgraham: note that we can configure any branch as the default brancjh
[09:13] <darobin> which is what people will immediately be in when they clone
[09:13] <darobin> for ReSpec I use gh-pages as the master branch but made develop the default branch
[09:13] <jgraham> darobin: Sure. But it just increases the friction if people get something different from what they are used to
[09:13] == Ms2ger` [~Ms2ger@public.cloak] has joined #HTMLT
[09:13] <darobin> that change alone made people do pull requests properly
[09:14] <darobin> it seems to me that only krisk and jgraham care strongly about this
[09:14] <krisk> We could just to pull requests from the CR branch
[09:14] <darobin> no no no, ideally we want pull requests to go to the right branch (but that's a separate topic)
[09:15] <darobin> gsnedders, tmpsantos: do you have an opinion here? Ms2ger and I seem not to care much
[09:15] <gsnedders> darobin: I agree with jgraham, basically.
[09:17] <krisk> So why is it bad to have people submit tests into the ED branch all the time?
[09:17] == Ms2ger [~Ms2ger@public.cloak] has quit [Ping timeout: 60 seconds]
[09:17] <darobin> can we say that's 2 to 1 amongst those who care and call it a day, or do you care strongly krisk?
[09:17] <krisk> ..then when a test is done they send a pull request to the CR branch and people review it?
[09:17] <darobin> krisk: ideally you'd want two flows
[09:18] <darobin> - for features that are in the CR, pull req to CR, which then also gets merged to master/ED
[09:18] <darobin> - for features that are next gen, pull req to master/ED (and that's it)
[09:19] <Ms2ger`> I disagree
[09:19] <krisk> let's stop in 5 minutes...though I'd like to hear what ms2ger says...
[09:19] <darobin> Ms2ger`: you want all PRs to ED, and then it's up to the reviewer to cherry pick that to CR?
[09:19] <Ms2ger`> Pull everything into trunk, and then just pick a subset for CR
[09:20] <Ms2ger`> darobin, not up to the reviewer, but up to someone who cares about the CR
[09:20] <darobin> Ms2ger`: I can live with that, but ideally the reviewer doing the pulling would at least ping whoever cares about CR
[09:20] <jgraham> We call it "master" in git land :p
[09:20] <Ms2ger`> darobin, thank you, I don't want you in my trunks
[09:20] <krisk> We have some good agreement but the branch stuff we'll need more time..
[09:21] <Ms2ger`> Let's just go with master
[09:21] <darobin> ok, I'll pick whatever and we can rename the branch later, it's trivial
[09:22] <darobin> I'll put it all in temp/* anyway before we agree and deploy
[09:22] <krisk> we don't have consensus...
[09:22] <krisk> Since we have other details to work out..
[09:22] <jgraham> But we do have running code!
[09:22] <darobin> krisk: yes, but I can keep updating my proposal to match what's consensual
[09:23] <darobin> I want to keep having something concrete
[09:23] <Ms2ger`> Do we have rough consensus? :)
[09:24] <darobin> how about I make the changes we discussed today, and send an email to the list when it's done
[09:24] <krisk> I think we need to send out the two proposals to the list
[09:24] <darobin> then people who want things differently can bring that up
[09:24] <jgraham> darobin: That sounds quite reasonable to me
[09:25] <krisk> Also I assume the the w3c will be able to update the w3c-test to for each branch in Hg?
[09:25] <darobin> hg is another issue
[09:25] <darobin> ideally, I think we should just kill it once we have GH set up the way we like
[09:25] <Ms2ger`> The only disagreement seems to be about the naming of the branch
[09:25] <Ms2ger`> And darobin suggests that's easy to change
[09:26] <darobin> (of course, W3C will keep a git clone, and w3c-test will have content per branch)
[09:26] <Ms2ger`> So let's just go ahead with whatever
[09:26] <krisk> So then w3c will setup Git?
[09:26] <darobin> krisk: for instance, http://www.w3.org/html/wg/drafts/ has nine drafts produced from multiple branches of the same repo
[09:26] <krisk> ..on a w3c server?
[09:26] <darobin> krisk: we'll set it up enough to ensure we have a clone of the repo
[09:27] <darobin> but the canonical repo ought to be the github one
[09:27] <krisk> How about this...
[09:27] <krisk> A) setup git on the w3c hg server
[09:27] <krisk> b) create the branches
[09:27] <krisk> C) get it to prop to w3c-test
[09:28] <darobin> krisk: if by setting up git on the hg server you mean as in fully configured with LDAP integration, a web interface and all, I don't think that's going to happen
[09:28] <krisk> Let's not try to make this about moving to github
[09:28] <darobin> besides, I don't see why it's needed
[09:30] <darobin> krisk: but we will certainly have a git mirror to ensure that we have the whole data should anything happen
[09:30] <darobin> (we already do for the HTML WG repo for instance)
[09:30] <krisk> I think this needs to be all part of the proposal(s)...
[09:30] <darobin> err, sure, sorry, I thought we'd agreed to move to GH
[09:31] <Ms2ger`> I doubt it
[09:31] <darobin> what's the alternative?
[09:32] <Ms2ger`> dvcs.w3.org
[09:32] <jgraham> Well
[09:32] <jgraham> hg isn't going to work unless we find > 0 people that understand how branches are supposed to work there
[09:32] <jgraham> So we have to move to *git*
[09:33] <jgraham> Allowing people to submit tests through github has a large number of advantages
[09:33] <jgraham> e.g. they already wrote a mostly idiot0prof pull-request UI
[09:33] <krisk> I'd expect that where ever we tell people to submit/work on tests we should expect it to get very messy overtime and with more participants
[09:33] <darobin> yeah, I've read the documentation on hg branches back to front and then some, and I still don't understand them
[09:34] <jgraham> So when we do TTWF and similar people already understand the toolchain
[09:34] <darobin> so unless we can track down the guy who wrote down the feature, and pray that he hasn't moved on to git in disgust in the meantime, I don't think that dvcs is even on the radar
[09:34] <jgraham> But the alternative is that we mainly host on dvcs.w3.org/git/ and use critic for review and expect people to figure our our own toolchain
[09:34] <jgraham> Which won't have fancy UI
[09:35] <jgraham> Because we're not in the VCS UI business
[09:35] <darobin> at TTWF most participants just asked where the GH repo was
[09:36] <jgraham> (The UI in that case would be "pull from github, but only push to critic")
[09:36] <jgraham> ("and then when accepted push to w3c")
[09:36] <darobin> for web hackers, it's "GitHub it or it doesn't exist"
[09:36] <jgraham> (which seems strictly harder than "fork on github, push to your fork")
[09:36] <darobin> indeed
[09:37] <jgraham> Although I will note that if github turns evil or dies, we can always fall back to the second path
[09:37] <jgraham> s/second/first/
[09:38] <jgraham> and it will still be better than today
[09:38] <krisk> I think what we are saying is this...
[09:38] <jgraham> And now I have to catch a bus
[09:38] <jgraham> In fact, I wonder if I will make it...
[09:38] <krisk> hope you make your bus!
[09:38] <krisk> let's meet again next tuesday...
[09:39] <krisk> I think what we discussed was..
[09:39] <krisk> setup dvcs.w3.org/git
[09:39] <darobin> krisk: you started "I think what we are saying is this..." - can you send the end of that sentence to the list maybe? so we get jgraham and all involved
[09:39] <darobin> (or type it here and we'll catch up on minutes)
[09:39] <krisk> make it so that someone you check in here or check into someother public git repository...
[09:40] <krisk> I'll copy the IRC and delete the the * comments
[09:40] <darobin> 'k
[09:40] <krisk> and send it to the list..
[09:40] <darobin> note that setting up anything involved git on the dvcs server will require systeam intervention, and they tend to be spread thin
[09:40] <darobin> it's certainly not something they'd let me do
[09:41] <darobin> and we'd also have to explain why github isn't good for us when it is for all the other groups that use it
[09:41] <darobin> s/involved git/involving git/
[09:42] <krisk> thanks for everyone time...meeting is now ending...
[09:42] <darobin> I will update the repo with the consensus and mail the list

-----Original Message-----
From: Kris Krueger [mailto:krisk@microsoft.com] 
Sent: Monday, December 10, 2012 5:47 PM
To: 'public-html-testsuite@w3.org'
Subject: HTML Testing Task Force Conf Call Agenda 12/11/2012

Agenda

As discussed last week we will be meeting again on IRC continuing the discussion on test organization.

-Thanks!

IRC #HTMLT
Time 17:00-18:00 UTC (11:00am-12:00pm Boston local)

Received on Tuesday, 11 December 2012 19:54:00 UTC