I'll add a Wiki page for the table of existing feature flags and their descriptions.<div><br><br><div class="gmail_quote">On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I think we're talking about a couple of different things now:<br>
<br>
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.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Maciej<br>
<div><div><br>
<br>
On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote:<br>
<br>
> (Re-sending from the right address...)<br>
><br>
> I'd +1 Adam's point.<br>
><br>
> It would be great if we can do something like "webkit-build --gtk<br>
> --stable", "webkit-build --chromium --canary" or "webkit-build<br>
> --nightly" where the script read the central configuration file and<br>
> find an appropriate configuration. In this way, there would be no<br>
> duplication we should maintain.<br>
><br>
> Even though some ports currently don't support switches through<br>
> build-webkit, we can gradually switch over to the central list-based<br>
> configuration settings by, for example, generating features.gypi,<br>
> FeatureDefines.xcconfig or a set of flags for autoconf.<br>
><br>
> Also the feature-table page could be generated from the list. We can<br>
> even start from simply generating an HTML from the machine-readable<br>
> configuration file, then integrate it to each build system.<br>
><br>
> Although it might be overkill, I personally prefer this kind of "don't<br>
> repeat youself" direction.<br>
> --<br>
> morrita<br>
><br>
> On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
>><br>
>> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote:<br>
>><br>
>> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>> wrote:<br>
>>><br>
>>> I think you raise a good point. Another point worth mentioning is that<br>
>>> sometimes a feature can be complete and useful in one port, but half-baked<br>
>>> in another (for example, fullscreen API was shipped in Safari and at the<br>
>>> same time present but non-functional in Chrome).<br>
>>><br>
>>> I think in the past, port owners have made clear that they want to own the<br>
>>> final decisions on what features are enabled in their ports.<br>
>>><br>
>>> But we as a community could do better, by having a shared recommendation<br>
>>> of what features we think should be enabled in shipping releases. In some<br>
>>> cases, this may not match the settings on trunk, as some features may be<br>
>>> desirable to enable for experimental builds, but not in shipping product.<br>
>>> For features that we recommended disabling, ideally we'd identify a reason.<br>
>>> And in some cases, those might be port-specific issues.<br>
>><br>
>><br>
>> Right. Even just having a list of new features with flag(s) to<br>
>> enable/disable and the status (e.g. list of outstanding bugs) on wiki page<br>
>> will be helpful.<br>
>><br>
>> For example, vertical writing mode doesn't work on Windows, Chromium, etc...<br>
>> but port owners may not necessarily realize that the feature is enabled by<br>
>> default and each port needs to modify the code that draws text.<br>
>><br>
>><br>
>> I personally think such a page would be a good idea. I'd love to hear input<br>
>> from more folks on whether this is a good idea and what the right approach<br>
>> is.<br>
>><br>
>> Cheers,<br>
>> Maciej<br>
>><br>
>> _______________________________________________<br>
>> webkit-dev mailing list<br>
>> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
>> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
>><br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>TAMURA Kent <br>Software Engineer, Google <br><br><br><br>
</div>