[webkit-dev] Runtime setting for incomplete features

[Jeremy Orlow]

On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Oct 5, 2009, at 9:17 PM, Darin Fisher wrote:
>
> On Mon, Oct 5, 2009 at 6:43 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Oct 5, 2009, at 6:20 PM, Sam Weinig wrote:
>>
>>
>>
>> On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson <atwilson at google.com> wrote:
>>
>>  I'm surprised to see these objections coming up now, weeks after the
>>> original discussion, and only after my patch has landed in the tree.
>>>
>>
>> Sorry, I seemed to have missed that thread. I did however file a bug as
>> soon as the first runtime switch went in.
>>
>>
>>> That said, I agree that in an ideal world, we'd hide window.audio, shared
>>> workers, notifications, local storage, databases, session storage and any
>>> other runtime/platform-disabled API from enumerations - I just agree with
>>> Maciej that this isn't a hugely important issue, since these features are
>>> only runtime-disabled while under development and so not widely available
>>> anyway.
>>>
>>
>> I obviously disagree with Maciej on this. I think it is bad to break
>> developers expectations for feature detection.
>>
>>
>> My comments were specifically based on the Chrome team's plans to only
>> have the runtime switch in "dev channel" builds, and always fully compile
>> features out in release product.
>>
>
> That's not how we do things.  Sorry for the confusion.  What ships in dev
> channel goes to beta provided it passes the quality metrics.  What ships in
> beta goes to stable again provided it passes the quality metrics.  We do not
> change the build configuration when promoting a build.
>
>
> Jeremy Orlow said said (in an earlier email):
>
> "I'm also going to send mail to chromium-dev proposing that we never ship
> anything but a "dev channel" browser with such experimental features
> compiled in for the reasons we've discussed here."
>

I did, and Darin rejected it.  :-)

I guess we should have brought the discussion back here after we talked
about the Chromium half of that.  Sorry.


> Others seemed to agree with that line of thinking. If his suggestion was
> rejected, then yes, we should go back to the drawing board. Shipping
> partly-detectable but disabled features in production builds would be bad.
>
> Therefore, it is essential that feature detection is done correctly even in
> dev channel builds.  My apologies if you have received mixed messages on
> this.
>
>
> I'm concerned that the cost in code complexity for enabling runtime
> switching with perfect detectability properties may be high. The drivers for
> that cost seem (at first glance) like inessential aspects of the Chromium
> development process. Is there any fundamental reason that production builds
> have to ship with runtime-switchable experimental features?
>
> Regards,
> Maciej
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091005/e1a66f9e/attachment.html>