[webkit-dev] Proposal to enable compile flags only for EWS run
abarth at webkit.org
Thu Aug 16 10:00:22 PDT 2012
Why not just build and run the tests locally? This sounds like a CSS
feature that should more or less work the same for every port.
On Thu, Aug 16, 2012 at 9:53 AM, Peter Beverloo <peter at chromium.org> wrote:
> Depending on how much longer the feature will be in development, it may not
> be worth setting up a new bot. Bruno seems to be mostly interested in
> getting EWS results, whereas results on the waterfall would only show up
> after committing the actual change.
> Something you could consider is to have a patch specifically crafted for
> getting EWS results. To take the Chromium Linux EWS bot as an example, you
> can enable the feature in Chromium's features.gypi and remove the SKIP entry
> from the TestExpectations file (these changes need to be in the patch
> itself), asking the bot to compile everything and run layout tests for the
> feature. As this patch wouldn't be intended to be committed, don't request
> review or commit, and manually click on the "Request EWS" button on the
> Bugzilla page.
> If you're using webkit-patch, this would work:
> webkit-patch upload --no-review -m "Patch for EWS"
> Similar changes can be made to enable it for other ports as well, i.e. for
> the Mac port which also runs layout tests. A downside of this is that you
> have to maintain a certain boilerplate of code for enabling your feature,
> and that you have to remember to remove this boilerplate when uploading the
> patch for review and/or commit. I guess you could set up a git workflow to
> make this a lot easier, though.
> On Thu, Aug 16, 2012 at 5:38 PM, Adam Barth <abarth at webkit.org> wrote:
>> Currently the EWS bots use the same configuration as the bots on
>> build.webkit.org. We do that so they give accurate information about
>> what effect a given patch is going to have on the state of the tree
>> when the patch lands. If we build using different flags on the EWS
>> than on build.webkit.org, they lose that predictive power.
>> What we've done to address this issue in the past is to set up a new
>> bot on build.webkit.org that builds and tests with flag turned on.
>> For example, during the development of flexbox, we had a flexbox bot
>> that the folks who worked on flexible cared about and everyone else
>> ignored. I believe we did the same thing for grid layout.
>> I'd recommend setting up a separate bot on build.webkit.org.
>> On Thu, Aug 16, 2012 at 6:13 AM, Bruno Abinader <brunoabinader at gmail.com>
>> > Hi WebKit :)
>> > As previously discussed, we decided that compile flag only was the
>> > best option for CSS3 Text Decoration feature set (landed in
>> > http://trac.webkit.org/changeset/125716 ). I believe this was a
>> > general decision and got promptly implemented as such (however I still
>> > maintain a runtime flag patch at
>> > https://bugs.webkit.org/show_bug.cgi?id=93966 in case it is ever
>> > needed).
>> > What I want to discuss is an issue that raises with the decision to
>> > only have compile flag: As it comes disabled by default, further
>> > development on this feature will not be able to be checked by EWS or
>> > any other build bot. This affects layout tests regression checking and
>> > compile-time error checking, so I wonder how can we manage to fix
>> > this? I have some proposals below:
>> > 1) Propose a special "EWS-only" build variable to contain compile
>> > flags not enabled by default.
>> > I might not know how difficult it would be to implement this, but
>> > sounds like a clean approach to me.
>> > 2) Change compile flag value to become enabled by default.
>> > I believe this is not possible because, as discussed earlier, it would
>> > prematurely expose the feature to the web.
>> > 3) Add runtime flag, so compile flag would be enabled by default, but
>> > runtime flag would be disabled.
>> > That was I actually proposed in
>> > http://lists.webkit.org/pipermail/webkit-dev/2012-August/021878.html
>> > (CSS Regions implements like this, with both compile and runtime
>> > flags).
>> > Assuming that 2) and 3) are not possible due to previous discussion,
>> > this makes me wonder if 1) is feasible. I believe other feature flags
>> > might had the same situation before, so how you guys managed to check
>> > for errors? I appreciate your input and feedback!
>> > Best regards,
>> > --
>> > Bruno de Oliveira Abinader
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
More information about the webkit-dev