W3C

- DRAFT -

SV_MEETING_TITLE

17 May 2011

See also: IRC log

Attendees

Present
Regrets
Chair
SV_MEETING_CHAIR
Scribe
jgraham

Contents


<krisk> If someone else joins the IRC we can potentially setup the conf call

<krisk> Though we can use IRC (like normal)

<krisk> We have no new bugs on approved tests

<krisk> Bug Link http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&component=testsuite&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_i

<krisk> I wanted to continue to discussion from our last meeting

<krisk> I re-read the IRC from our last meeting and was not 100% sure why you didn't want to move in this direction

Because I don't think it makes any sense

A testsuite is continuously developing. It makes sense to have a process of continuous improvement ("continuous integration") rather than a process based around arbitarily set dates and stabilisation and so on

Particularly because there isn't any stabilisation to do

It's a *testsuite*. In itself it can't regress

Unless the spec is changed or something

We already know which tests are considered approved

We have a whole folder for that

(I would like to switch to using branches, but different discussion)

It doesn't do anything to magically fix the submitted-not-approved problem

<krisk> It should help get more people to particpate

Because there is still no incentive for people to spend their time reviewing tests

<krisk> ..and would allow them a timeframe to potentially plan for reviewing tests

Whereas writing tests will continue because it is typically a byproduct of other activity

The coverage problem is a technical issue that we haven't solved

Why would more people participate because every few months we said "OK stop writing tests and review tests instead!"

<krisk> Because a schedule would exists and one could plan/allocate time if they were aware of a schedule

Or even if we don't do that and just pick arbitary revisions to call "alpha", "beta", etc.

I don't see how a schedule would help anyone, really

Do we know of anyone who is not submitting tests due to the lack of a schedule?

It's certainly not a problem for Opera; we write tests when we implement features

That seems highly unlikely to change

Possibky your claim is that there is no technical benefit but the psychological effect of being told "next Wednesday we will call what we have alpha 2" will be helpful to motivate people?

*Possibly

<krisk> Well we could try it and see what occurs...

Well of course if you want to call some revisions "releases" or "milestones" or whatever that is fine

I don't think it should have any impact on people submitting tests though

<krisk> if doesn't actually change particpation then we can abandon the doing "releases" or "milestones"

I mean I am happy as long as there is no change in the process of the group because we are x days from a milestone

<krisk> people can always submit tests just like today..

<krisk> the only change would be to create a branch at a point in time and then ask for feedback on all tests at that point in time

Fine. Then I expect the change to mostly be a no-op, but if you think it is helpful then I can't really complain

Since we are continuously asking for feedback on all submitted but unapporoved tests that seems like it isn't much of a chnge

<krisk> how are the parser tests going?

They need to be updated a bit because I made some stuff in the harness private

and I need to update to latest html5lib

But that is no problem

<krisk> were you able to get a basic parser test to pass in all browsers?

<krisk> The document.write seems to work in all browsers but not the data URI (fails in chrome)

Yeah, I think that is a chrome bug due to over-enthusiastic blocking of reading the DOM in data URI child frames

I'm not really sure of a good way to work around that

<krisk> it may not be a bug - rather by design

<krisk> ...for security

Well the spec will have to rule one way or the other

It doesn't make much sense as a security restriction to me

<krisk> I have not tried safari - let me check...

<krisk> seems to work...

<krisk> I might be good to make the first test just pass on all browsers

<krisk> ...then you could know that the harness stuff works

<krisk> I need to head off - shall we adjourn?

Sure

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/05/17 15:45:36 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/wrong/changed/
Succeeded: s/motivation/benefit/
No ScribeNick specified.  Guessing ScribeNick: jgraham
Inferring Scribes: jgraham

WARNING: No "Topic:" lines found.


WARNING: No "Present: ... " found!
Possibly Present: krisk
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 17 May 2011
Guessing minutes URL: http://www.w3.org/2011/05/17-htmlt-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]