On 04/11/2013 11:40 AM, Joshua Cranmer wrote:
On 4/11/2013 1:33 PM, ISHIKAWA,chiaki wrote:
(2013/04/11 23:43), Joshua Cranmer wrote:
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer
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 03/29/2013 06:01 PM, Gregory Szorc wrote:
snip/
I highly recommend against defining MOZ_OBJDIR in terms of relative
paths. You're implicitly creating a dependency on cwd. This is handy
in a few use cases but it's a giant foot gun. Instead, do something
like |mk_add_options
On 03/19/2013 07:33 AM, Joshua Cranmer wrote:
On 3/18/2013 11:27 PM, Jeff Hammel wrote:
On 03/15/2013 11:33 AM, Gregory Szorc wrote:
Our build config has a number of areas where metadata is centrally
defined and a module or component's configuration is fragmented in
the source tree. Here
On 03/18/2013 09:45 PM, Gregory Szorc wrote:
On 3/18/2013 9:27 PM, Jeff Hammel wrote:
On 03/15/2013 11:33 AM, Gregory Szorc wrote:
Our build config has a number of areas where metadata is centrally
defined and a module or component's configuration is fragmented in
the source tree. Here
I'll point out and really this is about all I have to say on this thread
that while perf testing (that is, recording results) may bewell, not
easy, but not too awful that rigorous analysis of what the data means
and if there is a regression is often hard since it is often the case,
as
On 02/21/2013 05:41 AM, Justin Lebar wrote:
Can guidance be
provided as to where to get such things for commonly-run versions of Linux?
It's also easy to install hg using pip or easy_install. You can get
either of these tools using your distro's package manager.
(easy_install is usually called
On 02/20/2013 01:42 PM, L. David Baron wrote:
My main question is: what will continue to work and what will stop
working?
For example, which of these ways of running mochitests will still
work and which won't:
TEST_PATH=layout/style/test make mochitest-plain
On 01/04/2013 01:01 PM, Mike Hommey wrote:
On Sat, Jan 05, 2013 at 07:49:22AM +1100, Nicholas Nethercote wrote:
On Fri, Jan 4, 2013 at 12:23 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
But putting sts in would be
reasonable for those that don't have |smarttab| set.
So it sounds like
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 subset of Talos
tests. So I'm suggesting
If the exact width/height could be found for each test then these could
be marked in a manifest (theoretically, not speaking to the existing
reftest manifest format per se). Then reftest could be modified to take
a (e.g.) --resoltuion 400x400 argument and the test runner passing over
any test
On 08/22/2012 12:29 PM, Gregory Szorc wrote:
Switching to something else also has another advantage: the
opportunity for a clean slate. I'm hoping we'll use the opportunity to
scrape away 10+ years of cruft.
I support the sentiment, though this reasoning always makes me cautious,
as it
12 matches
Mail list logo
