On Mon, Oct 5, 2009 at 9:45 PM, Maciej Stachowiak <m...@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 <m...@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 <atwil...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
