On Tue, Feb 14, 2012 at 11:09 AM, Maciej Stachowiak <[email protected]> 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 <[email protected]> wrote: >>> >>> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: >>> >>> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak <[email protected]> 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 >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
