On Tue, Oct 2, 2012 at 7:12 PM, Jeff Gilbert wrote:
> As an additional data point, my experience is that the interactivity of my
> machine is not noticeably impacted when I overcommit with -j12 on my
> 4core/8thread i7 windows machine.
Right, I think we've discussed this issue enough. Everyone
As an additional data point, my experience is that the interactivity of my
machine is not noticeably impacted when I overcommit with -j12 on my
4core/8thread i7 windows machine. Task manager shows the cores often pegged at
100%, but the machine basically behaves normally. Neither is my Ubuntu
8
Correction. PB&J is booked this week. Those in MV should find another room.
We'll use the ProgramManagement vidyo room.
- Original Message -
> With people off helping B2G let's spend some time this week taking a
> good look at the open projects and the progress that we expect to
> make in
With people off helping B2G let's spend some time this week taking a good look
at the open projects and the progress that we expect to make in Q4.
Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy
Dial-in: conference# 95346
US/International: +1 6
On 2012-10-02 6:00 PM, Karl Tomlinson wrote:
Ben Hearsum writes:
On 09/29/12 12:58 AM, Kannan Vijayan wrote:
1. A patch that is expected to succeed, but you want to run it through
try to verify.
For "optimistic" pushes, we expect that the patch goes from green =>
green. For "pessimistic" p
On 2012-10-02 6:17 PM, Bobby Holley wrote:
The general problem as I see it is that talos try doesn't go orange if
there's a regression (because we detect regressions over time), and
checking the results against a baseline revision is kind of a pain, even
with talos-compare. So I think most develo
The general problem as I see it is that talos try doesn't go orange if
there's a regression (because we detect regressions over time), and
checking the results against a baseline revision is kind of a pain, even
with talos-compare. So I think most developers ignore it, and those who
have the gumpti
Ehsan Akhgari writes:
> Over in bug 796087, I'm proposing for us to remove the -t all try server
> flag. The rationale is that the set of Talos tests vary greatly and most
> of the people who test performance are only interested in a subset of Talos
> tests.
Frequently enough people change code
On Fri, 28 Sep 2012 11:44:56 -0700, Gary Kwong wrote:
>> http://blog.johnford.org/new-mac-builders-ssds-j-settings/
>
> Quoted from that blog:
>
> "I did find that it is better to set the -j setting too high than
> it is to set it too low."
>
> -Gary
Better in terms of build time, which is the ri
Ben Hearsum writes:
> On 09/29/12 12:58 AM, Kannan Vijayan wrote:
>> 1. A patch that is expected to succeed, but you want to run it through
>> try to verify.
>
>> For "optimistic" pushes, we expect that the patch goes from green =>
>> green. For "pessimistic" pushes we expect a listing of all ora
On 10/01/2012 04:40 PM, Jeff Hammel wrote:
On 10/01/2012 04:32 PM, Ehsan Akhgari wrote:
Over in bug 796087, I'm proposing for us to remove the -t all try server
flag. The rationale is that the set of Talos tests vary greatly and
most
of the people who test performance are only interested in a
> Boxes which run performance tests are separate from boxes which run
> unit tests, right? If so, I'd be interested to know what the
> breakdown is ignoring Talos, since that's not usually on the critical
> path for m-i or try, and since that would presumably skew the load
> measured above towards
> That's just the load in terms of # of pushes. Load in terms of % time spent
> on the various branches is pretty different. For the past 30 days, here's
> the breakdown of time of builds and tests spent on the top 4 branches:
> 39.93% mozilla-inbound
> 31.00% try
> 6.91% mozilla-central
> 6.22% mo
On 01/10/12 10:51 PM, Justin Lebar wrote:
For case 1., an idea that has been floated here and again (in Automation and
Tools and Release Engineering, anyway) is landing directly from try ->
inbound (or central) for green try pushes. However, this isn't a small
endeavor, both for the reasons of bu
I think this is a great idea.
On Tue, Oct 2, 2012 at 1:32 AM, Ehsan Akhgari wrote:
> Over in bug 796087, I'm proposing for us to remove the -t all try server
> flag. The rationale is that the set of Talos tests vary greatly and most
> of the people who test performance are only interested in a s
15 matches
Mail list logo
