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

[Hajime Morrita]

On Tue, Feb 14, 2012 at 11:09 AM, 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.

You are right. And talking about (1) is fine for this discussion to be focused.
I went off the point.

Regards,
--
morrita

>
> 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
>>>
>