On 8/15/13 2:50 PM, L. David Baron wrote:
On Thursday 2013-08-15 14:11 -0700, Gregory Szorc wrote:
I feel that having developers develop on the same toolchain as
official builds (producing bit-identical builds if possible) would
cut down on patch development costs due to reducing the frequency o
On 16/08/2013 10.22, Neil wrote:
> Paolo Amadini wrote:
>> A new about:config preference named "browser.download.useJSTransfer"
>> enables the browser and the Downloads Panel to use the Downloads.jsm
>> module instead of nsIDownloadManager as the back-end. The browser must
>> be restarted for the p
On 2013-08-12 6:14 PM, Matt Brubeck wrote:
I've posted a patch that would change how the graph server sends email
when a performance *improvement* is detected:
https://bugzilla.mozilla.org/show_bug.cgi?id=904250
This is really great.
Can other addresses be CC'ed when this specifically (and in
... goes to Blake Kaplan!
He deleted 11,336 lines of code when he excised the old about:blank
parser in bug 903912.
btw, I didn't write any fancy scripts to scrape hg logs. github has
pretty graphs for mozilla-central. However, the stats are skewed by
merges and backouts.
https://github.c
On 16/08/2013 15:14, Adam Roach wrote:
What I'm worried about, if we start disabling various modules, is that
we're going to have regressions that go unnoticed on developer systems,
blow up on m-i, and then take a _long_ time to track down.
They shouldn't take a long time to track down - a simp
> - Remove all conditional feature configuration from configure. WebRTC et al
> are always
> on. Features should be disabled dynamically (prefs), if at all.
Note that Fabrice has seen sizable memory-usage wins on B2G by
disabling non-web features such as printing and XUL. That alone is,
in my
On 16.08.2013 16:23, Andrew McCreight wrote:
>
> - Original Message -
>> I think the key argument against this approach is that system components
>> are never truly isolated. Sure, some of them can be compiled out and
>> still produce a working system. That doesn't mean that testing without
- Original Message -
> I think the key argument against this approach is that system components
> are never truly isolated. Sure, some of them can be compiled out and
> still produce a working system. That doesn't mean that testing without
> those components is going to have good test cov
I think the key argument against this approach is that system components
are never truly isolated. Sure, some of them can be compiled out and
still produce a working system. That doesn't mean that testing without
those components is going to have good test coverage.
What I'm worried about, if
On Fri, Aug 16, 2013 at 05:43:22PM +0800, Andreas Gal wrote:
>
> First of all, thanks for raising this. Its definitely a problem that
> needs fixing.
>
> I am not convinced by your approach though. In a few months from now
> disabling WebRTC is like calling for the DOM or JS or CSS to be
> disabl
First of all, thanks for raising this. Its definitely a problem that
needs fixing.
I am not convinced by your approach though. In a few months from now
disabling WebRTC is like calling for the DOM or JS or CSS to be disabled
in local developer builds. It will become a natural part of the cor
Hi everyone,
There's been a lot of traction recently about our builds getting slower
and what we could do about it, and what not.
Starting with bug 904979, I would like to change the way we're thinking
about default flags and options. And I am therefore opening a discussion
about it.
The main th
Paolo Amadini wrote:
A new about:config preference named "browser.download.useJSTransfer" enables
the browser and the Downloads Panel to use the Downloads.jsm module instead of
nsIDownloadManager as the back-end. The browser must be restarted for the preference to
take effect.
Support for th
13 matches
Mail list logo
