[webkit-dev] When should we turn on new features?

[TAMURA, Kent]

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 <tkent at 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 <mjs at 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 <mjs at apple.com>
>> wrote:
>> >>
>> >> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:
>> >>
>> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <mjs at 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 at lists.webkit.org
>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>

>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev




> --
> TAMURA Kent
> Software Engineer, Google






-- 
TAMURA Kent
Software Engineer, Google




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120315/d7550891/attachment.html>