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

[Alexis Menard]

On Mon, Feb 13, 2012 at 11:09 PM, 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.

Hi,

I think one is totally useful and more than welcome. I would say that
the page should sit in the SVN so that whenever someone add a feature
the file had to be updated too. Also when someone add some UI bits for
a given port he can also update the file/page accordingly. The closer
this file is to the code the more chance it has to be up to date.

In QtWebKit we had
http://trac.webkit.org/wiki/QtWebKitSupportedStandards (but not up to
date) to track which release comes with what. It's missing the last
release funny enough.

There will be an initial work on each port to fill the default values
but hey nothing comes for free.

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



-- 
Alexis Menard (darktears)
Software Engineer
INdT Recife Brazil