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

[Adam Barth]

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 <peter at 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 <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
>> >
>> >
>
>