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 <pe...@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 <aba...@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 <brunoabina...@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@lists.webkit.org >> > http://lists.webkit.org/mailman/listinfo/webkit-dev >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
