W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Length of LC comment period

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 7 Dec 2009 14:34:37 +0000 (UTC)
To: Maciej Stachowiak <mjs@apple.com>, Marcos Caceres <marcosc@opera.com>
Cc: Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>
Message-ID: <Pine.LNX.4.62.0912071419540.14026@hixie.dreamhostps.com>
On Mon, 7 Dec 2009, Maciej Stachowiak wrote:
> 
> Note though: process-wise, Web Storage being in LC *is* a blocker to the 
> Widgets specification going to REC. Per W3C Process, a specification 
> cannot go to PR or REC unless all of its dependencies are at REC. It's 
> true though that it would not be a blocker to going to CR.

As far as I can tell (from our discussion on IRC and from my memory of the 
requirements), there is a pubrules suggestion that CR specs should only 
depend on CR+ specs, and PR specs should only depend PR+ specs, but it's 
neither a hard rule, nor in the W3C process.


On Mon, 7 Dec 2009, Marcos Caceres wrote:
> On Mon, Dec 7, 2009 at 7:14 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 7 Dec 2009, Marcos Caceres wrote:
> >>
> >> Sorry Ian, you are assuming you are the only one that can edit that 
> >> spec. If you want help with editing the spec or with the test suite, 
> >> just ask. I'm not saying I'll do it, but I can ask at Opera for one 
> >> of the WHATWG superstars to take it over. WDYT? or is it just too 
> >> entangled in HTML 5 to let someone else edit it?
> >
> > If Opera has people who have time to edit, there are _far_ more 
> > important things for us to have edited than Web Storage. DOM Core, for 
> > instance.
> 
> No offense, but I didn't know Google dictated Opera's, an other 
> companies, business objectives :)

The "us" in my statement above was meant to refer to the Web at large, not 
Google. I'm not trying to dictate your business objectives, but from the 
perspective of the Web's overall health, having DOM Core edited would be 
far more valuable than having Web Storage go to CR early.


> > Anyway, my point was that even if I did have time to edit the spec, it 
> > would be a bad idea to accelerate the process. Reviewing a spec takes 
> > time, finding problems takes time, and if we rush it we'll just screw 
> > it up.
> 
> Yes, I totally got that and completely agree. However, we have a number 
> of people that have implemented this that could be pressed for feedback.

Implementors of Web Storage have sent plenty of feedback. I'm confident 
that there are no known issues currently other than the storage mutex 
issue. Problems can't be squeezed out at will -- they take time to 
discover. Shortening the Last Call window to make progress faster is like 
trying to shorten the baking time for a cake by cooking it hotter. What 
you get in the end doesn't smell nice.


> Also, creating a test suite for Web Storage would allow us to find at 
> least some spec bugs quickly which someone else could fix in the spec 
> while you are busy with HTML5 and the other specs you are working on. 
> Might help cut a month or two from your work schedule.

Yes, if anyone would like to write a test suite, that would be extremely 
useful, independent of the Last Call window. As the spec's editor I don't 
think it would be wise for me to write the test suite anyway (since I'd 
end up writing tests that check what I think the spec says, not what it 
actually says).


> Again, if you need some help with something, please ask. It doesn't need 
> to be editing, it could be test suite or whatever.

A test suite and a solution to the storage mutex problem that all the 
browser vendors are willing to implement (which doesn't break the API and 
which doesn't introduce subtle bugs) would both be extremely helpful in 
accelerating the process after LC.

Test suites for the other specs in this batch would also be awesome.


> > Web Storage in particular has _already_ resulted in one of the biggest 
> > screwups of the last few years in the Web standards space (for which I 
> > take full responsibility) because of rushing implementations.
> 
> Cheer up, I can think of _much_ worst things that have popped out of the 
> W3C onto the Web than Web Storage:)

Yeah but they typically have minimal impact on the deployed Web, unlike 
the storage mutex problem.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 7 December 2009 14:35:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT