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 <aba...@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 <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
