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

[Ryosuke Niwa]

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 <rniwa at webkit.org> wrote:

> Great. Thanks!
>
> On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent <tkent at 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 <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
>>>> Software Engineer
>>>> Google Inc.
>>>>
>>>>
>>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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/20120315/e182dcb5/attachment.html>