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

[Ryosuke Niwa]

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/b825cbfa/attachment.html>