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

[Peter Beverloo]

It depends on the kind of feature you're working on, indeed.

While I don't know what Bruno's use-case is, In the case of text
decoration, I guess it could involve testing the complex test code paths
which can be different for port/platform combinations.

Peter

On Thu, Aug 16, 2012 at 6:00 PM, Adam Barth <abarth at webkit.org> wrote:

> 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.
>
> Adam
>
>
> 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.
> >
> > 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/b2fbd4ef/attachment.html>