[webkit-dev] When should we turn on new features?
Hajime Morrita
morrita at chromium.org
Mon Feb 13 16:21:53 PST 2012
(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
>
More information about the webkit-dev
mailing list