> If we really wanted to know, either someone would have to spend some time
> doing this over and over, or we'd have to use Telemetry with some A/B testing.
This would actually be a pretty easy thing to do, to a first
approximation anyway. Just turn off PGO on Windows for one nightly
build and se
On Thursday, October 18, 2012 4:59:10 AM UTC-7, Ted Mielczarek wrote:
> If you're interested in the benchmark side of things, it's fairly easy
> to compare now that we build both PGO and non-PGO builds on a regular
> basis. I'm having a little trouble getting graphserver to give me recent
> data
On Wednesday, October 17, 2012 11:00:13 PM UTC-7, Mike Hommey wrote:
> If you copy omni.ja from the PGO build to the opt build, you'll be able
> to see if everything comes from that. We're planning to make that
> currently PGO-only optimization run on all builds. (bug 773171)
Excellent suggestion,
On 10/17/2012 06:27 PM, Gregory Szorc wrote:
I wish it were easier. If this pattern ever becomes prevalent, we should
probably move the Python + JS harness to somewhere more central. File a
bug against me and I'll happily refactor the code in services/ to be
more generic and shareable.
Thanks f
Hello,
The Graphics meeting will take place this Monday at 2:30 PM US/Pacific
time. That could be Tuesday in your timezone.
Please first add your agenda items there:
https://wiki.mozilla.org/Platform/GFX/2012-October-22
* Not every Monday at 2:30 PM Pacific Time
* +1 650 903 0800 x92 Conf# 9936
Inbound now requires Python 2.6:
https://hg.mozilla.org/integration/mozilla-inbound/rev/09dc2dc1fc9f
Expect this to hit central in the next day or two.
If you find a distro that doesn't ship Python 2.6, we have a tool in the
tree to perform system bootstrapping (python/mozboot). We should teac
On 2012-10-19 12:13 PM, Dao wrote:
On 18.10.2012 20:05, Ehsan Akhgari wrote:
If your patch falls in a range which
causes more than 4% Ts regression, it will be backed out by our sheriffs
together with the rest of the patches in that range, and you can only
reland after you fix the regression by
hi;
We need to close the trees for 10hours on Sunday 21oct2012, from 8am-6pm
PDT, in order to do network upgrades in MTV and SCL1 datacenters. This
downtime is to allow for 8 hours of Ops work, followed by 2 hours of
RelEng spinning systems back up. The scl1 core upgrade is needed in
preparat
>> If your patch falls in a range which
>> causes more than 4% Ts regression, it will be backed out by our sheriffs
>> together with the rest of the patches in that range, and you can only
>> reland after you fix the regression by testing locally or on the try
>> server.
Our tools for comparing ta
On 18.10.2012 20:05, Ehsan Akhgari wrote:
If your patch falls in a range which
causes more than 4% Ts regression, it will be backed out by our sheriffs
together with the rest of the patches in that range, and you can only
reland after you fix the regression by testing locally or on the try server
On 18/10/12 06:44 PM, Justin Lebar wrote:
>> Do we still have the bug where a test that finishes first, but is from a
>> later cset (say a later cset IMPROVES Ts by 4% or more) would make us
>> think we regressed it on an earlier cset if that earlier talos run
>> finishes later?
>>
>> Such that we
On 2012-10-19 11:39 AM, Armen Zambrano G. wrote:
Is there a place where this will be document?
I would like to keep an eye on what gets added or point people at it.
Not that I know of! Please feel free to start a wiki page or something.
;-)
Ehsan
__
Is there a place where this will be document?
I would like to keep an eye on what gets added or point people at it.
This is awesome!
Looking forward to see how it goes.
thanks Ehsan
On 2012-10-18 2:05 PM, Ehsan Akhgari wrote:
Hi everyone,
As part of our efforts to get more value out of the Ta
13 matches
Mail list logo
