Re: Length of LC comment period

Sent from my iphone

On Dec 7, 2009, at 3:34 PM, Ian Hickson <ian@hixie.ch> wrote:

> 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.

So hang on... Why are going to LC if this is such a massive issue? Is  
this issue clearly marked in the spec with a link to at least an email  
thread where the problem is described?

>
> -- 
> Ian Hickson               U+1047E                ) 
> \._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _ 
> \  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'-- 
> (,_..'`-.;.'
>

Received on Tuesday, 8 December 2009 14:05:44 UTC