On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
FYI: Upgrading binutils to 2.23.2 did not help.
(Well, at least I got a better memory usage report when
memory was exhausted. ld printed out that it fails to allocate this many
bytes after having allocated the total amount. They are
On 03 April 2013 15:21:33, Neil wrote:
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
renamed ;-)
Agreed - TBPL's successor is going to be called something other than
TBPL2 (name chosen so far is treeherder).
Best wishes,
Ed
In general you'll have much more success running these benchmarks on
tryserver rather than trying to run them locally. Even if you got the
test working, there's no guarantee that your local benchmark results
will have any bearing on the benchmark results on our servers. (In
particular, the
(2013/04/03 16:32), ishikawa wrote:
On (2013年04月03日 15:32), Mike Hommey wrote:
On Wed, Apr 03, 2013 at 02:22:35PM +0900, ishikawa wrote:
FYI: Upgrading binutils to 2.23.2 did not help.
(Well, at least I got a better memory usage report when
memory was exhausted. ld printed out that it fails
Thanks Justin! Can you suggest what try syntax I can use please? I don't see
a TPS option in the try syntax builder page.
http://trychooser.pub.build.mozilla.org/
Justin Lebar於 2013年4月3日星期三UTC+8下午11時47分58秒寫道：
In general you'll have much more success running these benchmarks on
tryserver
On 2013-04-03 10:32 AM, Ed Morley wrote:
On 03 April 2013 15:21:33, Neil wrote:
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
renamed ;-)
Agreed - TBPL's successor is going to be called something other than
TBPL2 (name chosen so far is treeherder).
I disagree. TBPL2
You can't run TPS via tryserver; it isn't run in buildbot at all. It
can't, since it uses live Sync servers.
Raymond, the problem you're experiencing is likely due to changes in
mozprocess/mozrunner API's that TPS hasn't been updated to handle. Can
you file a bug about this, and assign it
On 3/4/13 15:32, Ed Morley wrote:
On 03 April 2013 15:21:33, Neil wrote:
Since tinderboxpushlog no longer uses tinderbox, maybe it should get
renamed ;-)
Agreed - TBPL's successor is going to be called something other than
TBPL2 (name chosen so far is treeherder).
I presume it'll be at
I just tested this myself and found that it works. The problem is in
your command-line:
2. runtps --binary=/Users/raymond/Documents/mozilla-central/obj-ff-dbg/
--binary needs to be the full path of the binary, not the directory to it.
The error message could certainly be improved. :)
Let
Yesterday a number of people discussed future plans for the WebAPI team.
Our discussion resulted in the ideas and comments that are on this
wiki page:
https://wiki.mozilla.org/WebAPI/PlannedWork
We'll add items to that page as time goes by and we'll pop items off it
as we work on them.
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual merge to m-c and
you're done.
3. If your try push is not green, update your patch(es) and
Another potential problem with this approach is that we will have more
merge changes in m-c, which generally screws with hg bisect. Personally
I already have enough trouble with hg bisect to the point where I don't
use it because I can't trust it. This may be a legitimate problem for
some, but
If anything this should improve the experience of bisecting, because
you'll be able to bisect known-good csets on m-c and only at the end
step in to the merge csets which may or may not be good.
Right now we say that when people push a patch queue to m-c every
patch should be green, but in
Stepping back: [
This issue is really a special case of This patch compiles fine in my
local configuration, but it busts the build for $OTHER_PLATFORM.
The general solution to this class of problems is a try push, with
builds on at least one platform other than your local config (if not all
On 04/03/2013 04:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual
On Wed, Apr 03, 2013 at 04:59:31PM -0700, Jeff Hammel wrote:
On 04/03/2013 04:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push
On 4/3/13 4:11 PM, Gregory Szorc wrote:
I pulled the raw builder logs from
https://secure.pub.build.mozilla.org/builddata/buildjson/ and assembled
a tab-separated file of all the builds for 2013-03-17 through 2013-03-23:
https://people.mozilla.com/~gszorc/builds-20130317-20130323.txt.bz2
On 2013-04-03 7:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual
On 2013-04-03 7:11 PM, Gregory Szorc wrote:
On 4/3/13 3:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
1. Take the latest green m-c change, commit your patch(es) on top of
it, and push it to try.
2. If your try push is green, flag it for eventual merge
On 2013-04-03 9:10 PM, Clint Talbert wrote:
On 4/3/2013 4:28 PM, Joshua Cranmer wrote:
On 4/3/2013 4:31 PM, Kartikaya Gupta wrote:
For what it's worth, I do recall there being release engineering talk
about some sort of autoland feature (which would automatically land
any patch that passed
On Wed, Apr 03, 2013 at 08:55:36PM -0400, Ehsan Akhgari wrote:
On 2013-04-03 7:44 PM, Joshua Cranmer wrote:
On 4/3/2013 5:36 PM, L. David Baron wrote:
On Wednesday 2013-04-03 17:31 -0400, Kartikaya Gupta wrote:
Instead of running {mochitest-*,reftest,crashtest,xpcshell,marionette}
on every
I suggest adding an Auto branch between Try and Central. Advantages:
* Pulling from Central is safe, because it only gets csets that passed
both Try (as individual developer pushes) and Auto (as a group).
* Infrastructure load will be slightly lower, because everyone's pushes
to Try will
On 2013-04-03 10:59 PM, Jeff Hammel wrote:
So I'm not sure I understand:
1. This will incur a significant increase in our infra resource usage
since all of these patches have to do a full try run. We simply cannot
afford that in today's world where we're struggling against wait times
and
23 matches
Mail list logo
