[webkit-dev] A not-quite baked proposal for moving pixel baselines out of trunk

Jarred Nicholls jarred at sencha.com
Mon Sep 12 16:11:35 PDT 2011

On Mon, Sep 12, 2011 at 1:48 PM, Adam Barth <abarth at webkit.org> wrote:

> Leandro's recent message reminded me that there was some discussion on
> this list about the burden caused by storing and maintaining pixel
> baselines for an ever-growing list of configurations.  I've been
> working on a proposal for moving pixel baselines to a "branch" so that
> they don't bother most folks.
> Unfortunately, I haven't been able to work out all the details yet.
> Here's a somewhat rough, work-in-progress proposal.  If you like this
> approach, I can spend more time trying to solve the remaining
> problems.
> == Motivation ==
> Maintaining pixel test results in svn.webkit.org for the various
> Chromium configuration imposes a number of costs on the WebKit
> community:
> All members of the community need to store these results locally when
> they create a checkout of WebKit.
> Updating the pixel results creates churn in the project that increases
> the time required to update a working copy and makes it more difficult
> to understand what is actually changing in the project.
> As the Chromium port grows in complexity, there is pressure from the
> Chromium project to expand the number of test configurations,
> increasing these costs on the WebKit community.
> == Proposal (Work-in-progress) ==
> One option is to stop running pixel test altogether, but that
> decreases test coverage and costs correctness.  Another possibility is
> to store the pixel results in a location where they are largely
> invisible to the rest of the WebKit community.  For example, we could
> store the pixel results for chromium-linux the following location:
> http://svn.webkit.org/repository/webkit/PixelResults/chromium-linux
> Chromium contributors could then use gclient and DEPS to map these
> results into their working copies and non-chromium contributors could
> safely ignore any changes in the PixelResults “branch”.
> FIXME: What about non-platform specific results?
> == Problems ==
> The main reason this proposal is half-baked is I haven't quite been
> able to work out how folks can do some common operations:
> 1) Land patch with expected image failures (+ revert)
> 2) Land patch with new image baselines (+ revert)
> 3) Land new baselines
> Because the pixel results and trunk are in the same SVN repo, we
> should be able to do these things atomically, but dealing with the
> sparse checkout is kind of tricky.
> Another big question mark is how this would work for contributors who
> use git.  When git mirrors an SVN repro, it only mirrors "trunk", so
> the PixelResults directory wouldn't exist in the git version of the
> repository.

git-svn would be the fallback - I'd rather take razor blades to my eyes.
 But this is a noble effort in general, thanks.

Do we need to do anything to alleviate history in the git mirror?  I'd love
to clone 25MB and not 2.1GB.

> Thoughts?
> Adam
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Jarred Nicholls, Senior Software Architect
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110912/0b5de48e/attachment-0001.html>

More information about the webkit-dev mailing list