In that case, he might want to start with one port, get that working well, and then expand to the other ports.
Adam On Thu, Aug 16, 2012 at 10:03 AM, Peter Beverloo <pe...@chromium.org> wrote: > 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
