FWIW, Chromium has version-specific diffs between XP and Vista/Win-7.
I don't remember off-hand how bad the diffs where, but comparing the
files in:
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/ruby
http://src.chromium.org/viewvc/
On Nov 12, 2009, at 6:59 PM, Ojan Vafai wrote:
> On Thu, Nov 12, 2009 at 3:48 PM, Adam Roben wrote:
> On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote:
>> 2. Can grab layout test results from the try servers. This would reduce the
>> need/occurence of committing Mac expectations and then cleaning u
Hm, interesting - I have to admit I just now saw that most (all?) test that
use non-English text are marked as Skipped for Windows (i.e., are in
LayoutTests/platform/win/Skipped). Now, if there is a fundamental reason why
such tests can't just be re-baselined (rendering incompatibilities between
Wi
To clarify, I think abarth's proposal is great and we shouldn't block it on
other things a try-server could provide. Would just be nice to keep the
"make writing patches more efficient" use-case in mind as we add other
infrastructure to avoid needing, for example, a whole different set of
servers f
On Thu, Nov 12, 2009 at 3:51 PM, Eric Seidel wrote:
> I think Ojan is used to Chromium's world where there is a layout-test
> rebaseling tool which knows how to suck expected results off of the
> chromium try-bots, including new pixel test results. So he (and
> others) are used to posting their p
On Nov 12, 2009, at 6:38 PM, Ojan Vafai wrote:
> 2. Can grab layout test results from the try servers. This would reduce the
> need/occurence of committing Mac expectations and then cleaning up other
> platforms post commit.
Without being able to see the loaded page on that platform, how do you
I agree that this design doesn't solve the problem of writing patches
more efficiently. That's not the goal. The goal is to reduce review
latency by automating the mechanical parts of the review process.
Adam
On Thu, Nov 12, 2009 at 3:38 PM, Ojan Vafai wrote:
> This approach doesn't lend itse
I think the main reason why we don't yet have a try server is that we block
it on stuff like this...which is nice to have.
It seems like we could get something basic up that worked for 90% of cases
and then iterate on something more featureful. I think Adam has the right
idea here.
J
On Thu, No
This approach doesn't lend itself as well to trying patches before putting
them up for review. Specifically, I want to be able to try patches without
spamming everyone with bugzilla mail. This is solvable in this
bugzilla-based approach, but it doesn't lend itself to this as
naturally, e.g. presum
Agreed. Running every r=? patch through such a build-service is
insecure. However if Adam wishes to run it on his own hardware, I
certainly have no objections to such. :)
-eric
On Thu, Nov 12, 2009 at 2:49 PM, Mark Rowe wrote:
>
> On 2009-11-12, at 14:43, Adam Barth wrote:
>
>> On Thu, Nov 12,
Ok. The only run stuff uploaded by committers automatically?
Maybe have a web page committers can visit to submit (i.e. vouch for)
patches to be run through the bots?
J
On Thu, Nov 12, 2009 at 2:52 PM, Brian Weinstein wrote:
> What if someone changed build-webkit or the build procedure in one
On 2009-11-12, at 14:50, Jeremy Orlow wrote:
> That sounds good to me.
>
> As for the security issues: It seems like we could build code from anyone but
> only run the tests from committers.
Building involves running code too. build-webkit, makefiles for dependencies,
scripts in Xcode projec
What if someone changed build-webkit or the build procedure in one of the
vcproj's?
On Nov 12, 2009, at 2:50 PM, Jeremy Orlow wrote:
> That sounds good to me.
>
> As for the security issues: It seems like we could build code from anyone but
> only run the tests from committers.
>
> On Thu, No
That sounds good to me.
As for the security issues: It seems like we could build code from anyone
but only run the tests from committers.
On Thu, Nov 12, 2009 at 2:43 PM, Adam Barth wrote:
> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote:
> > 1) People are already confused about how to handl
On 2009-11-12, at 14:43, Adam Barth wrote:
> On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote:
>> 1) People are already confused about how to handle the recently-added
>> commit-queue flag. Adding an extra flag is going to increase the confusion.
>
> I chatted with Eric about how to solve thi
On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote:
> 1) People are already confused about how to handle the recently-added
> commit-queue flag. Adding an extra flag is going to increase the confusion.
I chatted with Eric about how to solve this problem. One option is to
just try every change th
On Thu, Nov 12, 2009 at 12:41 PM, Jeremy Orlow wrote:
> It's so easy to have code that builds on one platform but not another. Even
> if the try servers were only builders to begin with, I think they'd provide
> a lot of value to the project.
That's a good idea, especially for ports that have pe
On Thu, Nov 12, 2009 at 1:04 PM, Mark Rowe wrote:
> On 2009-11-12, at 11:37, Adam Barth wrote:
>> 1) Contributor posts patch for review.
>> 2) Committer marks patch with the try? flag.
>> 3) The try-queue downloads, applies, builds, and tests the patch.
>> 4) If all systems are go, the try-queue m
On 2009-11-12, at 11:37, Adam Barth wrote:
> 1) Contributor posts patch for review.
> 2) Committer marks patch with the try? flag.
> 3) The try-queue downloads, applies, builds, and tests the patch.
> 4) If all systems are go, the try-queue marks the patch as try+.
> Otherwise, it marks the patch
Seconded (or Thirded). I'd been working on a try-server using Chromium's
try-change.py, but this seems like a much cleaner way to handle it, and ties
into the Bugzilla workflow much better than my solution, and would be much
easier to limit who can set the try bit, based on what we decide the po
It's so easy to have code that builds on one platform but not another. Even
if the try servers were only builders to begin with, I think they'd provide
a lot of value to the project.
On Thu, Nov 12, 2009 at 11:43 AM, Kenneth Christiansen <
kenneth.christian...@openbossa.org> wrote:
> I think tha
I think that sounds like a really good idea, and I can see my self
using that when touching cross platform code.
Kenneth
On Thu, Nov 12, 2009 at 4:37 PM, Adam Barth wrote:
> As the project grows, we need to scale our processes to match. In
> large part, that means automating as much work as pos
As the project grows, we need to scale our processes to match. In
large part, that means automating as much work as possible.
Commit-queue has done a good job of solving the "land patches from
non-committers efficiently" problem, effectively removing that as a
pain point. I'd like to ask you to o
Hi,
WebKit/chromium is now a live directory. We have completed committing the
bulk of the Chromium WebKit API into WebKit/chromium and this code is now
integrated to Chromium.
Our next steps, as described below, are to commit a 2nd wave (much smaller)
of API additions, and to port DumpRenderTree
On Nov 11, 2009, at 6:56 PM, Chris Jerdonek wrote:
> What is the current thinking on all of the "using WTF::..." statements at the
> end of many header files in JSC? For example, what was the original reason
> behind including those, and is there any chance that they will be taken out
> at a l
25 matches
Mail list logo
