On 11/05/2013 07:35 AM, James Graham wrote:
On 05/11/13 15:20, Till Schneidereit wrote:
Do we have any way to identify tests that break particularly often for
specific areas? If so, we could create a mach command that runs just
these
tests and finishes quickly. Something like `mach canary-tes
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 bec
On 04/03/2013 06:33 PM, Ehsan Akhgari wrote:
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
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:
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 MOZ_OBJDIR=@TOPSRCDIR@/
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
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 so
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 are some examples:
3) xpcshell.ini master manifest. /testing/xpcshell/xpcshell.ini
defin
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 evide
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
_tests/testing/mochitest/runte
Hi,
As you may or may not know, the A*Team undertook a major effort to
improve the fidelity of Talos measurements last year, code named Signal
from Noise:
https://wiki.mozilla.org/Auto-tools/Projects/Signal_From_Noise . The
effort proved to be much more substantive than any of us guessed goin
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
wrote:
But putting sts in would be
reasonable for those that don't have |smarttab| set.
So it sounds like the recommended mode l
Wild guess in the dark here, and assuming `py` == "the python
executable", it looks like you're using python 3.x (again wild guess)
whereas in python 2.x "print
getBuiltinOrNativeTypeName(self.params[0].realtype)" is valid syntax.
Again, its hard to guess from the limited information here.
Je
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 tha
On 09/28/2012 09:58 PM, Kannan Vijayan wrote:
On 12-09-28 10:03 PM, Seth Fowler wrote:
On Sep 28, 2012, at 6:28 PM, Boris Zbarsky wrote:
The point is that the patches that _do_ need to land urgently are
blocked on lack of resources because people are wasting too many
cycles with unnecesary t
On 09/28/2012 10:12 PM, Chris Pearce wrote:
On 29/09/12 14:32, L. David Baron wrote:
On Friday 2012-09-28 22:16 -0400, Boris Zbarsky wrote:
On 9/28/12 10:03 PM, Seth Fowler wrote:
On Sep 28, 2012, at 6:28 PM, Boris Zbarsky wrote:
The point is that the patches that _do_ need to land urgently
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 11:19 PM, Mike Hommey wrote:
On Wed, Aug 22, 2012 at 01:38:22PM -0700, Gregory Szorc wrote:
On 8/22/12 1:00 PM, Ben Hearsum wrote:
On 08/22/12 12:43 PM, Jeff Hammel wrote:
If we do go with python, it would be nice to keep the configuration
files as much configuration as possible
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 oft
On 08/22/2012 06:50 AM, Benjamin Smedberg wrote:
On 8/21/2012 7:36 PM, Gregory Szorc wrote:
On the other end of the spectrum, we could have the build manifest
files be Python "scripts." This solves a lot of problems around
needing functionality in the manifest files. But, it would be a
pot
On 08/03/2012 11:38 AM, Benoit Jacob wrote:
2012/8/3 Jeff Hammel mailto:jham...@mozilla.com>>
I would argue HTML is a good, or even great, backing format. It's
what mozilla does. It is a real standard. There are a plethora of
tools to deal with HTML documents.
Replies inline.
On 08/03/2012 07:59 AM, Justin Lebar wrote:
While I personally don't understand some people's fascination with MediaWiki
syntax (I can't stand it, myself), I know this is a Big Deal to some people.
Let me try to help you understand.
It's not an issue of being "fascinated" with
On 08/03/2012 07:46 AM, Benoit Jacob wrote:
2012/8/3 Sheppy
On Friday, August 3, 2012 12:02:10 AM UTC-4, Benoit Jacob wrote:
The #1 problem for many people with the current MDN wiki was that it
didn't
offer mediawiki-compatible markup editing. It would be great to be able
to
use right a
24 matches
Mail list logo
