I was just going to ask about this. I glanced through the mozconfigs in the
tree for at least Linux debug, but it looks like it only has --enable-debug,
not even -O1. Maybe it's buried somewhere in there, but I didn't find it with a
quick look.
I took a look at the build log for WinXP debug, an
Marcell has been my intern on the DXR project these past months, and it's been
a privilege to work with him. From JavaScript analysis to Elasticsearch to
writing Haskell in Python, he's cut an impressive swath through the codebase,
and you can expect to see a lot of his handiwork deployed in the
On Mon, Aug 18, 2014 at 1:14 PM, Jed Davis wrote:
> Bobby Holley writes:
> [...]
> > If you find yourself itching to do something complicated, write a
> > mochitest-chrome test. The default template [2] now generates html files
> > (rather then XUL files), so the ergonomics there should be easie
Gregory Szorc wrote:
On 8/19/14 2:11 PM, Neil wrote:
Gregory Szorc wrote:
I think the underlying bug here is "mach mochitest doesn't work for
comm-central." It should. I'm sure there is a bug on file somewhere.
Fair enough, but for when it does work, what's the mach version of
python runt
I'm pretty sure the debug builds on our CI infrastructure are built
with optimization.
- Kyle
On Tue, Aug 19, 2014 at 3:42 PM, Joshua Cranmer 🐧 wrote:
> On 8/19/2014 5:25 PM, Ehsan Akhgari wrote:
>>
>> Yep, the debug tests indeed take more time, mostly because they run more
>> checks.
>
>
> Actu
On 8/19/2014 5:25 PM, Ehsan Akhgari wrote:
Yep, the debug tests indeed take more time, mostly because they run
more checks.
Actually, the bigger cause in the slowdown is probably that debug tests
don't have any optimizations, not more checks. An atomic increment on a
debug build invokes somet
No, fx-team is not affected by this experiment; we intend to target
mozilla-inbound only for this 1-week trial. The reason is that the
number of commits on m-i seems larger than fx-team, and therefore the
impacts should be more visible.
Jonathan
On 8/19/2014 3:19 PM, Matthew N. wrote:
On 8/
On Tue, Aug 19, 2014 at 02:49:48PM -0700, Jonathan Griffin wrote:
> On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
> >On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
> >>I would actually say that debug tests are more important for continuous
> >>integration than opt tests. At least in code I deal with, we
I know this is tangential but the small changes are the least tested
changes in my experience. The try push requirement for checkin-needed
has had a wonderful impact on the amount of times the tree is closed[1].
The tree is less likely to be closed these days.
David
[1] http://futurama.theaut
On 2014-08-19, 5:49 PM, Jonathan Griffin wrote:
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in code I deal with,
we have a ton of asserts to gu
On 8/19/14 12:22 PM, Jonathan Griffin wrote:
To assess the impact of doing this, we will be performing an experiment
the week of August 25, in which we will run debug tests on
mozilla-inbound on most desktop platforms every other run, instead of
every run as we do now. Debug tests on linux64 wil
Thank you, Boris, this explains my problem.
On Tue, 19 Aug 2014 15:10:38 -0400 Boris Zbarsky wrote:
>On 8/19/14, 2:52 PM, Look, Yuriy wrote:
>> I am building my code against Gecko 31 for Windows and a public C++ method
>> nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 d
On 8/19/2014 2:41 PM, Ehsan Akhgari wrote:
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for
continuous integration than opt tests. At least in code I deal with,
we have a ton of asserts to guarantee behavior, and we really want
test cover
On 8/19/14 2:11 PM, Neil wrote:
Gregory Szorc wrote:
I think the underlying bug here is "mach mochitest doesn't work for
comm-central." It should. I'm sure there is a bug on file somewhere.
Fair enough, but for when it does work, what's the mach version of
python runtests.py?
mach mochitest
I also agree about coalescing better. We are looking at ways to do that
in conjunction with
https://wiki.mozilla.org/Auto-tools/Projects/Autoland, which we'll have
a prototype of by the end of the quarter. In this model, commits that
are going through autoland could be coalesced when landing
On 2014-08-19, 3:57 PM, Jeff Gilbert wrote:
I would actually say that debug tests are more important for continuous
integration than opt tests. At least in code I deal with, we have a ton of
asserts to guarantee behavior, and we really want test coverage with these via
CI. If a test passes on
Gregory Szorc wrote:
I think the underlying bug here is "mach mochitest doesn't work for
comm-central." It should. I'm sure there is a bug on file somewhere.
Fair enough, but for when it does work, what's the mach version of
python runtests.py?
--
Warning: May contain traces of nuts.
__
Jonathan Griffin wrote:
Can you show us the command-line you're using?
../path/to/python runtests.py
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2014-08-19 1:55 PM, Benoit Girard wrote:
> Perhaps we should instead promote checkin-needed (or a similar simple)
> to coalesce simple changes together.
I would prefer to use 'checkin-needed' for more things, but am blocked
by the try-needed requirement. We need some way to bless small changes
I completely agree with Jeff Gilbert on this one.
I think we should try to coalesce -better-. I just checked the current
state of mozilla-inbound and it doesn't feel any of the current patch
really need their own set of tests because they're are not time
sensitive or sufficiently complex. Right no
Hello all,
I know that there is a bunch of confusion in the wake of the recent
reorganization of b2g, so let me set things straight. There is no new QE
department. The QA team is still the same folks, although part of it is in the
B2G org, part of it is in the Services org, and the core QA team
I would actually say that debug tests are more important for continuous
integration than opt tests. At least in code I deal with, we have a ton of
asserts to guarantee behavior, and we really want test coverage with these via
CI. If a test passes on debug, it should almost certainly pass on opt,
Our pools of test slaves are often at or over capacity, and this has the
effect of increasing job coalescing and test wait times. This, in turn,
can lead to longer tree closures caused by test bustage, and can cause
try runs to be very slow to complete.
One of the easiest ways to mitigate thi
On 8/19/14, 2:52 PM, Look, Yuriy wrote:
I am building my code against Gecko 31 for Windows and a public C++ method
nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does not
get resolved by Visual Studio 2010 linker.
This is a non-virtual non-inline method, with default (
On Tue, Aug 19, 2014 at 9:06 AM, Ed Morley wrote:
> Agreed that this case is possibly slightly different - however this change
> is merely exposing already flaky tests - and this change is very much
> overdue. If the tests mentioned are really that important, then could we
> please get people allo
Hi,
I am building my code against Gecko 31 for Windows and a public C++ method
nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does not
get resolved by Visual Studio 2010 linker. This is the only one that does not
get resolved for me, even though my code uses quite a few
(I'm trying to move this thread to firefox-dev, please send followups there.)
> Bug 1041569 - has been needinfo'd for 4 weeks, it is only disabling this on
> win debug, I don't know how to reduce that anymore, especially if nobody
> wants to look at it.
Not what I see - a needinfo request was r
Hi Marc,
Can you shed some background on the change in name from QA to QE? Does QE stand
for Quality Engineering, whereas QA is Quality Assurance? What are the
differences between the two? Do we now have two different teams/departments?
Thanks,
Jared
- Original Message -
> From: "Marc
Hi Neil,
Can you show us the command-line you're using?
Jonathan
On 8/19/2014 1:53 AM, Neil wrote:
Gregory Szorc wrote:
On 8/18/2014 4:45 PM, Neil wrote:
Time was that you could just python runtests.py to run mochitests.
Then we needed modules that you don't get in the default python, so
On 8/19/14 1:53 AM, Neil wrote:
Gregory Szorc wrote:
On 8/18/2014 4:45 PM, Neil wrote:
Time was that you could just python runtests.py to run mochitests.
Then we needed modules that you don't get in the default python, so
you had to invoke python from the virtualenv instead.
Now that doesn
On 19/08/2014 16:46, Gavin Sharp wrote:
A few issues here:
- This particular case (we're making broad changes to how the tests
run that causes many new failures) was not what that policy was meant
to cover. We need some leeway to handle this situation differently.
Agreed that this case is possi
On Tuesday, August 19, 2014 11:46:08 AM UTC-4, Gavin Sharp wrote:
> > Going with our test disabling policy
> > (https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy), I am going to
> > get ready and disable tests on Friday.
>
>
>
> A few issues here:
>
> - This particular case (we're mak
> Going with our test disabling policy
> (https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy), I am going to
> get ready and disable tests on Friday.
A few issues here:
- This particular case (we're making broad changes to how the tests
run that causes many new failures) was not what that
Since these are front-end tests you'd be better off sending this to firefox-dev.
- Kyle
On Tue, Aug 19, 2014 at 7:07 AM, jmaher wrote:
> It has been 3+ weeks since Vaibhav and I found the remaining issues with
> --run-by-dir (https://bugzilla.mozilla.org/show_bug.cgi?id=992911) for
> browser-c
It has been 3+ weeks since Vaibhav and I found the remaining issues with
--run-by-dir (https://bugzilla.mozilla.org/show_bug.cgi?id=992911) for
browser-chrome. Since then a few issues have been fixed, and many have been
ignored.
Going with our test disabling policy
(https://wiki.mozilla.org/S
Gregory Szorc wrote:
On 8/18/2014 4:45 PM, Neil wrote:
Time was that you could just python runtests.py to run mochitests.
Then we needed modules that you don't get in the default python, so you had to
invoke python from the virtualenv instead.
Now that doesn't work either, because it's tr
36 matches
Mail list logo
