[webkit-dev] When should we turn on new features?
tkent at chromium.org
Tue Mar 13 21:03:56 PDT 2012
I'll add a Wiki page for the table of existing feature flags and their
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.
> 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>
> >> 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>
> >>> 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
> >>> in another (for example, fullscreen API was shipped in Safari and at
> >>> same time present but non-functional in Chrome).
> >>> I think in the past, port owners have made clear that they want to own
> >>> final decisions on what features are enabled in their ports.
> >>> But we as a community could do better, by having a shared
> >>> of what features we think should be enabled in shipping releases. In
> >>> cases, this may not match the settings on trunk, as some features may
> >>> desirable to enable for experimental builds, but not in shipping
> >>> For features that we recommended disabling, ideally we'd identify a
> >>> 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
> >> will be helpful.
> >> For example, vertical writing mode doesn't work on Windows, Chromium,
> >> but port owners may not necessarily realize that the feature is enabled
> >> 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
> >> from more folks on whether this is a good idea and what the right
> >> 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
Software Engineer, Google
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev