[webkit-dev] Proposal to enable compile flags only for EWS run

[Peter Beverloo]

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.

Peter

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.
>
> Adam
>
>
> On Thu, Aug 16, 2012 at 6:13 AM, Bruno Abinader <brunoabinader at gmail.com>
> wrote:
> > 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
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120816/455bce20/attachment-0001.html>