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

[TAMURA, Kent]

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




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