Re: [webkit-dev] ENABLE flag cleanup strawman proposal
On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: I've updated the spreadsheet of all ENABLE flags to match TOT (as of this afternoon): https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=en_US#gid=0 I've gone through the list and marked some of them that we might want to change, listed below. I expect this list to be somewhat controversial. Please consider it as a starting point for discussion. This proposal introduces a new kinds of flag: DEBUG. A DEBUG flag is only that we expect will only be used by developers locally to debug WebKit. For example, ENABLE(DEBUG_MATH_LAYOUT) and ENABLE(SAMPLING_COUNTERS) are only used to debug locally, not to ship to end users. The main benefit of labeling these flags as DEBUG-only, for example as DEBUG(MATH_LAYOUT), is that contributors don't need to worry as much about breaking them. (Of course, we still shouldn't try to break them capriciously.) I'd like to emphasize again that this list is just a starting point for discussion. I look forward to your feedback. Thanks, Adam == Rename == ENABLE(DATABASE) = ENABLE(SQL_DATABASE) ENABLE(LEVELDB) = USE(LEVELDB) ENABLE(ON_FIRST_TEXTAREA_FOCUS_SELECT_ALL) = Should be an editing behavior ENABLE(OPENTYPE_SANITIZER) = USE(OPENTYPE_SANITIZER) ENABLE(SYMBIAN_DIALOG_PROVIDERS) = USE(SYMBIAN_DIALOG_PROVIDERS) ENABLE(TILED_BACKING_STORE) = USE(TILED_BACKING_STORE) == Always Disable (Delete Code) == ENABLE(APPLICATION_CACHE_DYNAMIC_ENTRIES) ENABLE(FTPDIR) ENABLE(ICONDATABASE) ??? ENABLE(WBXML) ENABLE(WCSS) ENABLE(XHTMLMP) == Always Enable == ENABLE(DETAILS) ??? ENABLE(DOM_STORAGE) ENABLE(EVENTSOURCE) ENABLE(INSPECTOR) ??? ENABLE(METER_TAG) ENABLE(OFFLINE_WEB_APPLICATIONS) ENABLE(PROGRESS_TAG) ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this feature, so maybe keep configurable.) ENABLE(WTF_MULTIPLE_THREADS) -- ggaren is already making this happen, right? ENABLE(XHR_RESPONSE_BLOB) = Gated by ENABLE(BLOB) ^^^ I think this one probably needs to remain since we haven't implemented the backend for XHR.responseType == Blob yet, but other (core) Blob related APIs are implemented. What about ENABLE(REQUEST_ANIMATION_FRAME)? -Darin ENABLE(XPATH) ENABLE(XSLT) == Mark as for Debugging == ENABLE(CODEBLOCK_SAMPLING) = DEBUG(CODEBLOCK_SAMPLING) ENABLE(DEBUG_MATH_LAYOUT) = DEBUG(MATH_LAYOUT) ENABLE(DEBUG_WITH_BREAKPOINT) = DEBUG(WITH_BREAKPOINT) ENABLE(FAST_MALLOC_MATCH_VALIDATION) = DEBUG(FAST_MALLOC_MATCH_VALIDATION) ENABLE(GC_VALIDATION) = DEBUG(GC_VALIDATION) ENABLE(OPCODE_SAMPLING) = DEBUG(OPCODE_SAMPLING) ENABLE(OPCODE_STATS) = DEBUG(OPCODE_STATS) ENABLE(REGEXP_TRACING) = DEBUG(REGEXP_TRACING) ENABLE(SAMPLING_COUNTERS) = DEBUG(SAMPLING_COUNTERS) ENABLE(SAMPLING_FLAGS) = DEBUG(SAMPLING_FLAGS) ENABLE(SAMPLING_THREAD) = DEBUG(SAMPLING_THREAD) ENABLE(WTF_MALLOC_VALIDATION) = DEBUG(WTF_MALLOC_VALIDATION) ENABLE(YARR_JIT_DEBUG) = DEBUG(YARR_JIT) ___ 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
Re: [webkit-dev] ENABLE flag cleanup strawman proposal
On Wed, Sep 14, 2011 at 11:06 PM, Darin Fisher da...@chromium.org wrote: On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: I've updated the spreadsheet of all ENABLE flags to match TOT (as of this afternoon): https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=en_US#gid=0 I've gone through the list and marked some of them that we might want to change, listed below. I expect this list to be somewhat controversial. Please consider it as a starting point for discussion. This proposal introduces a new kinds of flag: DEBUG. A DEBUG flag is only that we expect will only be used by developers locally to debug WebKit. For example, ENABLE(DEBUG_MATH_LAYOUT) and ENABLE(SAMPLING_COUNTERS) are only used to debug locally, not to ship to end users. The main benefit of labeling these flags as DEBUG-only, for example as DEBUG(MATH_LAYOUT), is that contributors don't need to worry as much about breaking them. (Of course, we still shouldn't try to break them capriciously.) I'd like to emphasize again that this list is just a starting point for discussion. I look forward to your feedback. Thanks, Adam == Rename == ENABLE(DATABASE) = ENABLE(SQL_DATABASE) ENABLE(LEVELDB) = USE(LEVELDB) ENABLE(ON_FIRST_TEXTAREA_FOCUS_SELECT_ALL) = Should be an editing behavior ENABLE(OPENTYPE_SANITIZER) = USE(OPENTYPE_SANITIZER) ENABLE(SYMBIAN_DIALOG_PROVIDERS) = USE(SYMBIAN_DIALOG_PROVIDERS) ENABLE(TILED_BACKING_STORE) = USE(TILED_BACKING_STORE) == Always Disable (Delete Code) == ENABLE(APPLICATION_CACHE_DYNAMIC_ENTRIES) ENABLE(FTPDIR) ENABLE(ICONDATABASE) ??? ENABLE(WBXML) ENABLE(WCSS) ENABLE(XHTMLMP) == Always Enable == ENABLE(DETAILS) ??? ENABLE(DOM_STORAGE) ENABLE(EVENTSOURCE) ENABLE(INSPECTOR) ??? ENABLE(METER_TAG) ENABLE(OFFLINE_WEB_APPLICATIONS) ENABLE(PROGRESS_TAG) ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this feature, so maybe keep configurable.) ENABLE(WTF_MULTIPLE_THREADS) -- ggaren is already making this happen, right? ENABLE(XHR_RESPONSE_BLOB) = Gated by ENABLE(BLOB) ^^^ I think this one probably needs to remain since we haven't implemented the backend for XHR.responseType == Blob yet, but other (core) Blob related APIs are implemented. What about ENABLE(REQUEST_ANIMATION_FRAME)? That might make sense to always enable. It seems to be very popular. Adam ENABLE(XPATH) ENABLE(XSLT) == Mark as for Debugging == ENABLE(CODEBLOCK_SAMPLING) = DEBUG(CODEBLOCK_SAMPLING) ENABLE(DEBUG_MATH_LAYOUT) = DEBUG(MATH_LAYOUT) ENABLE(DEBUG_WITH_BREAKPOINT) = DEBUG(WITH_BREAKPOINT) ENABLE(FAST_MALLOC_MATCH_VALIDATION) = DEBUG(FAST_MALLOC_MATCH_VALIDATION) ENABLE(GC_VALIDATION) = DEBUG(GC_VALIDATION) ENABLE(OPCODE_SAMPLING) = DEBUG(OPCODE_SAMPLING) ENABLE(OPCODE_STATS) = DEBUG(OPCODE_STATS) ENABLE(REGEXP_TRACING) = DEBUG(REGEXP_TRACING) ENABLE(SAMPLING_COUNTERS) = DEBUG(SAMPLING_COUNTERS) ENABLE(SAMPLING_FLAGS) = DEBUG(SAMPLING_FLAGS) ENABLE(SAMPLING_THREAD) = DEBUG(SAMPLING_THREAD) ENABLE(WTF_MALLOC_VALIDATION) = DEBUG(WTF_MALLOC_VALIDATION) ENABLE(YARR_JIT_DEBUG) = DEBUG(YARR_JIT) ___ 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
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
Responding to a few issues at once: On Sep 14, 2011, at 12:50 PM, Adam Barth wrote: One of the things I admire about the WebKit project is that historically the project has been very inclusive. One common thread that's woven through a number of recent discussions is that folks feel we've taken on too much complexity and that it's harder to make fundamental improvements to the engine. Maybe it's time to adjust that balance slightly, but I hope we adjust our behavior deliberately. Agreed. I think we can adjust toward putting more onus on port maintainers a step at a time, and see how things go. It may be a long-shot, but I really do believe that putting more onus on port maintainers has a chance to make WebKit *more* inclusive, not less, by bringing port maintainers into the fold of regular WebKit development. On Sep 14, 2011, at 1:00 PM, Patrick Gansterer wrote: IMO most of the is active questions come with a when do we remove the old code/port from trunk question. That's not very cool to hear after the hard upstreaming work. But that's only my personal view. I'm sorry that you keep getting this question, especially from me. :) On Sep 14, 2011, at 1:00 PM, Patrick Gansterer wrote: More interesting questing is: How do part time maintainers get informed about fundamental changes? I'd prefer cc'ing on a bug which might break a build. So it's possible for the maintainer to try to build with the patch locally and implement the missing parts. At least for me it's easier to fix compiler errors than answering questions about a possible build break on webkit-dev. ;-) I think some combination of forewarning in Bugzilla bugs and email to webkit-dev is the right approach here. Hopefully, all active maintainers, by definition, keep up with webkit-dev email. Direct CC is a harder plan for me to work with, because I want to make sure that I get in touch will all interested port maintainers at once, even if I don't a priori know who they are. On Sep 14, 2011, at 1:02 PM, Dirk Pranke wrote: Maybe we need a webkit-port-maintainers@ list that one could easily cc rather than trying to add people by hand? Sounds helpful. Not sure exactly how it would work, though. (How would you add yourself to the list?) On Sep 14, 2011, at 1:08 PM, Ryosuke Niwa wrote: Having said that, I think contributors should help maintaining ports that have bots on build.webkit.org or EWS bots. To the extent that a bot can make certain kinds of fixes obvious, I think that core contributors should indeed make obvious fixes. However, I'm not convinced that having a bot should convey any special privileges beyond that. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
On Thu, Sep 15, 2011 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote: On Sep 14, 2011, at 1:02 PM, Dirk Pranke wrote: Maybe we need a webkit-port-maintainers@ list that one could easily cc rather than trying to add people by hand? Sounds helpful. Not sure exactly how it would work, though. (How would you add yourself to the list?) Subscribe through the listserv, just like webkit-dev? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ENABLE flag cleanup strawman proposal
Thanks for the feedback thus far. I'm going to start working on some of the changes I perceive as less controversial. Please feel free to comment on bugs or reply to this thread if you have additional thoughts. The meta bug for this work is https://bugs.webkit.org/show_bug.cgi?id=68012. Adam On Wed, Sep 14, 2011 at 3:40 PM, Adam Barth aba...@webkit.org wrote: I've updated the spreadsheet of all ENABLE flags to match TOT (as of this afternoon): https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdHFVNUpFSDBudEF5WGM3WDNzQjI3Yncauthkey=CJCDiooKhl=en_US#gid=0 I've gone through the list and marked some of them that we might want to change, listed below. I expect this list to be somewhat controversial. Please consider it as a starting point for discussion. This proposal introduces a new kinds of flag: DEBUG. A DEBUG flag is only that we expect will only be used by developers locally to debug WebKit. For example, ENABLE(DEBUG_MATH_LAYOUT) and ENABLE(SAMPLING_COUNTERS) are only used to debug locally, not to ship to end users. The main benefit of labeling these flags as DEBUG-only, for example as DEBUG(MATH_LAYOUT), is that contributors don't need to worry as much about breaking them. (Of course, we still shouldn't try to break them capriciously.) I'd like to emphasize again that this list is just a starting point for discussion. I look forward to your feedback. Thanks, Adam == Rename == ENABLE(DATABASE) = ENABLE(SQL_DATABASE) ENABLE(LEVELDB) = USE(LEVELDB) ENABLE(ON_FIRST_TEXTAREA_FOCUS_SELECT_ALL) = Should be an editing behavior ENABLE(OPENTYPE_SANITIZER) = USE(OPENTYPE_SANITIZER) ENABLE(SYMBIAN_DIALOG_PROVIDERS) = USE(SYMBIAN_DIALOG_PROVIDERS) ENABLE(TILED_BACKING_STORE) = USE(TILED_BACKING_STORE) == Always Disable (Delete Code) == ENABLE(APPLICATION_CACHE_DYNAMIC_ENTRIES) ENABLE(FTPDIR) ENABLE(ICONDATABASE) ??? ENABLE(WBXML) ENABLE(WCSS) ENABLE(XHTMLMP) == Always Enable == ENABLE(DETAILS) ??? ENABLE(DOM_STORAGE) ENABLE(EVENTSOURCE) ENABLE(INSPECTOR) ??? ENABLE(METER_TAG) ENABLE(OFFLINE_WEB_APPLICATIONS) ENABLE(PROGRESS_TAG) ENABLE(SVG_ANIMATION) = Gated on ENABLE(SVG) ENABLE(SVG_AS_IMAGE) = Gated on ENABLE(SVG) ENABLE(SVG_DOM_OBJC_BINDINGS) = Gated on ENABLE(SVG) ENABLE(SVG_FONTS) = Gated on ENABLE(SVG) ENABLE(WEB_TIMING) ??? (I think Maciej has concerns about this feature, so maybe keep configurable.) ENABLE(WTF_MULTIPLE_THREADS) -- ggaren is already making this happen, right? ENABLE(XHR_RESPONSE_BLOB) = Gated by ENABLE(BLOB) ENABLE(XPATH) ENABLE(XSLT) == Mark as for Debugging == ENABLE(CODEBLOCK_SAMPLING) = DEBUG(CODEBLOCK_SAMPLING) ENABLE(DEBUG_MATH_LAYOUT) = DEBUG(MATH_LAYOUT) ENABLE(DEBUG_WITH_BREAKPOINT) = DEBUG(WITH_BREAKPOINT) ENABLE(FAST_MALLOC_MATCH_VALIDATION) = DEBUG(FAST_MALLOC_MATCH_VALIDATION) ENABLE(GC_VALIDATION) = DEBUG(GC_VALIDATION) ENABLE(OPCODE_SAMPLING) = DEBUG(OPCODE_SAMPLING) ENABLE(OPCODE_STATS) = DEBUG(OPCODE_STATS) ENABLE(REGEXP_TRACING) = DEBUG(REGEXP_TRACING) ENABLE(SAMPLING_COUNTERS) = DEBUG(SAMPLING_COUNTERS) ENABLE(SAMPLING_FLAGS) = DEBUG(SAMPLING_FLAGS) ENABLE(SAMPLING_THREAD) = DEBUG(SAMPLING_THREAD) ENABLE(WTF_MALLOC_VALIDATION) = DEBUG(WTF_MALLOC_VALIDATION) ENABLE(YARR_JIT_DEBUG) = DEBUG(YARR_JIT) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What is an active port? [WAS: Do you maintain OS(WINCE)?]
On Thu, Sep 15, 2011 at 12:26 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Sep 15, 2011 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote: On Sep 14, 2011, at 1:02 PM, Dirk Pranke wrote: Maybe we need a webkit-port-maintainers@ list that one could easily cc rather than trying to add people by hand? Sounds helpful. Not sure exactly how it would work, though. (How would you add yourself to the list?) Subscribe through the listserv, just like webkit-dev? fwiw, I could totally see that working. Here's how I would use it: In general I would ignore the email except when I was on duty for keeping things green. Then, I would watch it carefully and get the right people to help out with the Chromium side of things as needed. dave -- Dirk ___ 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
