On 2013-05-30 3:14 PM, Milan Sreckovic wrote:
I'm thinking C++, I imagine JS may have different answers or suggestions.
Since you mentioned C++, here is an example of an entire class [1] which
I had to invent so that I can test it [2] in C++. The Gecko consumer
derives [3] from this class, a
Thanks for starting this conversation, jst.
As an advocate of git in general, I actually think option #1
(maintaining both git and hg as first class citizens) makes a lot more
sense for us. The benefits of git in my opinion outweigh hg, but not to
a degree that would warrant paying the cost o
[TL;DR, I think we need to embrace git in addition to hg for
Firefox/Gecko hacking, what do you think?]
Hello everyone,
The question of whether Mozilla engineering should embrace git usage for
Firefox/Gecko development has come up a number of times already in
various contexts, and I think it's ti
On 5/30/13 3:14 PM, Milan Sreckovic wrote:
Add public accessors, even if they're (currently) only used by the unit tests.
If it doesn't hurt, this seems like a pretty good solution.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
h
> For example, a public method (which we want to test in the unit test) has a
> number of side effects, but we don't have the public accessors to examine all
> of those private side effects/state.
I had this problem with the B2G process priority tests.
>From a mochitest, I wanted to create a va
On 2013-05-30 3:14 PM, Milan Sreckovic wrote:
I'm thinking C++, I imagine JS may have different answers or suggestions.
Do we have a precedent or a preferred approach when unit testing requires
changes or additions to the code?
I've needed to do this in the past and resorted to an entirely di
That's an option I should have added to the list, you're right. It does mean
we are not exercising the code that we're shipping, but it's probably better
than nothing.
Milan
On 2013-05-30, at 3:46 PM, Joe Drew wrote:
> On 2013-05-30 3:14 PM, Milan Sreckovic wrote:
>> I'm thinking C++, I ima
I'm thinking C++, I imagine JS may have different answers or suggestions.
Do we have a precedent or a preferred approach when unit testing requires
changes or additions to the code?
For example, a public method (which we want to test in the unit test) has a
number of side effects, but we don't
Thanks for your feedback everyone. Most of the people who replied both
here and off-list agreed that foreground should be the default, so I
posted a patch on bug 863754 to do that when Firefox is launched using
mach. I encourage somebody to take the time and modify Firefox itself
to do that t
- Original Message -
> On 30/05/13 04:55, Mike Hommey wrote:
> > As someone that will soon be in UTC+9, and taking on the occasion
> > to
> > represent all the people in that timezone and surroundings, a
> > couple
> > hours before 3am is not very a great time to decide whether I'd
> > atte
That was a slip by hal, the date of the downtime is June 1, 2013, which is on a
Saturday.
Thanks for double checking,
--
~Justin Wood (Callek)
- Original Message -
From: "Kyle Huey"
To: "release"
Cc: "dev. planning" , "dev-tree-management"
, dev-platform@lists.mozilla.org
Sent: Wedn
I vote for foreground as a default as well! ++
On May 30, 2013, at 1:40 AM, Ehsan Akhgari wrote:
> On 2013-05-29 6:45 PM, André Reinald wrote:
>> I think the default behavior should stay as it is.
>> But I suggest having the mach script read a setting (from mozconfig or
>> elsewhere) to decide w
12 matches
Mail list logo
