Re: [webkit-dev] add NeedsRebaseline keyword to TestExpectations as a way to hande updating pixel tests?

2012-10-04 Thread Emil A Eklund
That sounds like a great idea!
It is too hard to do this right today and having an easy way to
indicate that a test needs to be rebaselined across some or a subset
of platforms would be great.

--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] A new test in a patch passes locally fails on ews

2012-10-04 Thread Emil A Eklund
What if we mail the zip files to the person that uploaded the patch?
That way the responsibility of managing the storage is shifted to the
author and the author still benefits from the results from all
platforms.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

2012-12-11 Thread Emil A Eklund
I'll have to disagree with you here.

If the build is broken and the gardener/build cop has a strong reason
to suspect that it was caused by a specific patch and the author is
unavailable then rolling that patch out is the right thing to do. It
might inconvenience the author but it is the responsibility of the
author and reviewer to make sure the patch didn't break anything.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

2012-12-11 Thread Emil A Eklund
On Tue, Dec 11, 2012 at 12:19 PM, Ojan Vafai  wrote:
> On Tue, Dec 11, 2012 at 12:17 PM, Emil A Eklund  wrote:
>>
>> I'll have to disagree with you here.
>>
>> If the build is broken and the gardener/build cop has a strong reason
>> to suspect that it was caused by a specific patch and the author is
>> unavailable then rolling that patch out is the right thing to do. It
>
>
> "author is unavailable" is the key statement here.

Indeed.

> That said, if your strong reason turned out to be incorrect, you should 
> recommit the patch, no?

That seems like a bad idea, someone that understands the patch should
recommit it. Ideally the original author.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

2012-12-11 Thread Emil A Eklund
On Tue, Dec 11, 2012 at 1:14 PM, Peter Kasting  wrote:
> On Tue, Dec 11, 2012 at 1:11 PM, Emil A Eklund  wrote:
>>
>> > That said, if your strong reason turned out to be incorrect, you should
>> > recommit the patch, no?
>>
>> That seems like a bad idea, someone that understands the patch should
>> recommit it. Ideally the original author.
>
>
> I don't understand your logic.  A patch landed, the sheriff thinks maybe it
> was bad and rolls it out, then it turns out it was a red herring.  Why is it
> not now the sheriff's responsibility to re-land?  After all, the patch was
> landed originally by people who understood it and hasn't been seen to cause
> any problems.

There might very well have been other changes that conflicts with it.
If it applies cleanly then I agree with you that whoever rolled it out
should reland it. If there are conflicts or if it requires merging in
any way though I'd argue that the original author needs to get
involved.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] For your consideration: Naming scheme for fooIfExists/ensureFoo

2013-06-18 Thread Emil A Eklund
On Tue, Jun 18, 2013 at 6:38 PM, Darin Adler  wrote:
> What do you think of these names instead?
>
> StyleResolver* optionalStyleResolver();
> StyleResolver& requiredStyleResolver();

+1, much clearer and the pointer vs reference makes it even more so.
Perhaps enough so that the required prefix could be dropped:

StyleResolver* optionalStyleResolver();
StyleResolver& styleResolver();
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Do we need subpixel layout (Was: Should SATURATED_ARITHMETIC_LAYOUT be forced when enabling SUBPIXEL_LAYOUT ?)

2013-08-01 Thread Emil A Eklund
As someone who worked on both subpixel layout and saturated layout
arithmetic I would strongly suggest that subpixel layout isn't used
without saturated arithmetic as the reduced range of supported values
with subpixel layout enabled makes numeric overflows rather common.
Combining the two makes sense to me but isn't my decision to make.

If you have any further questions or concerns about either I'd be
happy to help answer them as best I can.

Regards,
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Subpixel Layout Update

2011-10-28 Thread Emil A Eklund
On Fri, Oct 28, 2011 at 13:47, Eric Seidel  wrote:
> Most interesting is to see the branch diff.  Is that possible from the
> web?  Could you tell me what the magic svn command is if it's not
> possible?

The easiest seems to be the following:

svn diff --old http://svn.webkit.org/repository/webkit/trunk@98654
--new http://svn.webkit.org/repository/webkit/branches/subpixellayout
Source/

Where the magic revision number is the last revision we've merged into
the branch, in this case 98654. You can find the latest revision we've
merged by looking at the revision history here:
http://trac.webkit.org/log/branches/subpixellayout


--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Subpixel Layout Update

2011-10-28 Thread Emil A Eklund
On Fri, Oct 28, 2011 at 14:52, Eric Seidel  wrote:
> I've posted the current diff from the branch so that its easier to read.

Thanks Eric,

I'll make sure to update it periodically to make it easier to follow
our progress.

--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Subpixel Layout Update

2012-02-10 Thread Emil A Eklund
> I meant it would let us update the PNGs once instead of twice.

Ah, that's a good point. We're "only" touching about 500 pixel tests
so it wouldn't be too bad if we had to do it twice. Might be nice to
avoid though.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Moving to Git?

2012-03-09 Thread Emil A Eklund
On Fri, Mar 9, 2012 at 14:46, Adam Treat  wrote:
> Would be good to know who the remaining svn users are.  And who is using 
> git/git-svn now.  I'd love to see the breakdown.  Data is good.

I'm another svn user and while I'd prefer to keep using svn I'm not
opposed to migrating to git if that is what the majority wants.
Maintaining both certainly seems undesirable in the long run.

--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] CSS3 Selectors3 test suite

2012-03-22 Thread Emil A Eklund
On Thu, Mar 22, 2012 at 18:41, Ojan Vafai  wrote:
> I've recently been greening Chromium's expectations for css3/selectors3.
> ~10% of these test need interaction (e.g. hovering over a link or selecting
> text). Given that this is an imported test suite does it make sense to add
> the appropriate layoutTestController hooks? As it is, the tests aren't
> really verifying correctness.

Seems like a good idea.

> Also, this test suite is a great example of one that I think it would make
> more sense for us to check in reftest expected results instead of
> png+rendertreedump. These tests are explicitly testing selector matching
> only, so it would be easy to write reftests that have a high confidence of
> accurately verifying correctness. They'd only fail if we had some egregious
> bug such that we painted everything green as white. Presumably we'd notice
> such a bug through other means.

Again, I think that would be valuable (and lead to way fewer incorrect
failures and thus lowering the maintenance costs over time). As such
I'd gladly help with the conversion work if we do end up going down
that route.

--
Emil
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev