By the way, can we add a point of contact for each one of these features? I often find it hard to figure out who "owns" which feature/flag.
- Ryosuke On Thu, Mar 15, 2012 at 11:51 AM, Ryosuke Niwa <rn...@webkit.org> wrote: > Great. Thanks! > > On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent <tk...@chromium.org> wrote: > >> I made https://trac.webkit.org/wiki/FeatureFlags . >> I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some >> comments. Feel free to edit it! >> >> >> On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent <tk...@chromium.org> wrote: >> >>> I'll add a Wiki page for the table of existing feature flags and their >>> descriptions. >>> >>> >>> On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak <m...@apple.com> wrote: >>> >>>> >>>> I think we're talking about a couple of different things now: >>>> >>>> 1) Table of what the WebKit community as a whole (instead of individual >>>> point maintainers) thinks should be enabled in stable releases. This would >>>> be input to port maintainers looking to make a release. >>> >>> >>>> 2) Documenting what enable flags are actually on for given ports as >>>> shipped. Probably hard to gather this info, but might be useful input for >>>> the WebKit community. >>>> >>>> 3) Changing build systems to enable compiling "nightly" and "stable" >>>> versions from the same tree, so both modes are documented in trunk. >>>> Requires some coding for various build systems. >>>> >>>> I like (2) and (3), but I don't think they replace the usefulness of >>>> (1). I think the mention of "the feature-table page" is blending (2) and >>>> (1), which would serve different purposes. >>>> >>>> Regards, >>>> Maciej >>>> >>>> >>>> On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: >>>> >>>> > (Re-sending from the right address...) >>>> > >>>> > I'd +1 Adam's point. >>>> > >>>> > It would be great if we can do something like "webkit-build --gtk >>>> > --stable", "webkit-build --chromium --canary" or "webkit-build >>>> > --nightly" where the script read the central configuration file and >>>> > find an appropriate configuration. In this way, there would be no >>>> > duplication we should maintain. >>>> > >>>> > Even though some ports currently don't support switches through >>>> > build-webkit, we can gradually switch over to the central list-based >>>> > configuration settings by, for example, generating features.gypi, >>>> > FeatureDefines.xcconfig or a set of flags for autoconf. >>>> > >>>> > Also the feature-table page could be generated from the list. We can >>>> > even start from simply generating an HTML from the machine-readable >>>> > configuration file, then integrate it to each build system. >>>> > >>>> > Although it might be overkill, I personally prefer this kind of "don't >>>> > repeat youself" direction. >>>> > -- >>>> > morrita >>>> > >>>> > On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak <m...@apple.com> >>>> wrote: >>>> >> >>>> >> On Feb 13, 2012, at 1:21 PM, >>>> Ryosuke Niwa >>>> Software Engineer >>>> Google Inc. >>>> >>>> >>>> wrote: >>>> >> >>>> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <m...@apple.com> >>>> wrote: >>>> >>> >>>> >>> I think you raise a good point. Another point worth mentioning is >>>> that >>>> >>> sometimes a feature can be complete and useful in one port, but >>>> half-baked >>>> >>> in another (for example, fullscreen API was shipped in Safari and >>>> at the >>>> >>> same time present but non-functional in Chrome). >>>> >>> >>>> >>> I think in the past, port owners have made clear that they want to >>>> own the >>>> >>> final decisions on what features are enabled in their ports. >>>> >>> >>>> >>> But we as a community could do better, by having a shared >>>> recommendation >>>> >>> of what features we think should be enabled in shipping releases. >>>> In some >>>> >>> cases, this may not match the settings on trunk, as some features >>>> may be >>>> >>> desirable to enable for experimental builds, but not in shipping >>>> product. >>>> >>> For features that we recommended disabling, ideally we'd identify a >>>> reason. >>>> >>> And in some cases, those might be port-specific issues. >>>> >> >>>> >> >>>> >> Right. Even just having a list of new features with flag(s) to >>>> >> enable/disable and the status (e.g. list of outstanding bugs) on >>>> wiki page >>>> >> will be helpful. >>>> >> >>>> >> For example, vertical writing mode doesn't work on Windows, >>>> Chromium, etc... >>>> >> but port owners may not necessarily realize that the feature is >>>> enabled by >>>> >> default and each port needs to modify the code that draws text. >>>> >> >>>> >> >>>> >> I personally think such a page would be a good idea. I'd love to >>>> hear input >>>> >> from more folks on whether this is a good idea and what the right >>>> approach >>>> >> is. >>>> >> >>>> >> Cheers, >>>> >> 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 >>>> >>> >>> >>> >>> -- >>> TAMURA Kent >>> Software Engineer, Google >>> >>> >>> >>> >> >> >> -- >> TAMURA Kent >> Software Engineer, Google >> >> >> >> >> _______________________________________________ >> 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
