On Tue, Sep 4, 2012 at 9:39 PM, Mike Hommey wrote:
>
> On the other hand, the ccache miss rate is pretty high, at least it is
> for me, so in the end, ccache might not be a win at all.
That's what I've found, for my compiling patterns.
Nick
___
dev-pla
This Thursday, 11am PT, will be our last Snappy meeting before our work week.
Please add your items and status to the agenda before the call.
https://etherpad.mozilla.org/snappy
Dial-in: conference# 95346
US/International: +1 650 903 0800 x92 Conf# 95346
US toll free: +1 800 707 2533 (pin 369) C
On 12-09-02 12:33 AM, Justin Wood (Callek) wrote:
Taras Glek wrote:
* Joel will revisit maintaining Talos within mozilla-central to reduce
developer barriers to understanding what a particular Talos test result
means. This should also make Talos easier to run
To call out this point explicitly.
We'd discussed this, but due to current dev status and scheduling, drivers now
feel that there's a good chance of needing to branch B2G's Gecko before it's on
mozilla-release to limit risk to desktop/mobile, which would nullify any delays
meant to keep B2G tied to the next ESR.
In terms of long
On 8/31/2012 8:46 AM, Justin Lebar wrote:
There are extremely non-stable Talos tests, and relatively stable ones.
Let's focus on the relatively stable ones.
It's not exclusively a question of noise in the tests. Even
regressions in stable tests are sometimes hard to track down. I spent
two mo
On Tue, Sep 4, 2012 at 12:34 PM, Alex Keybl wrote:
> I'd like to provide everybody with an update about this plan. "B2G v1"
> platform work is continuing on mozilla-central as we speak, and therefore
> will not be a part of FF17 (currently on Aurora) given the risk of
> uplifting new work. Unfort
I'd like to provide everybody with an update about this plan. "B2G v1" platform
work is continuing on mozilla-central as we speak, and therefore will not be a
part of FF17 (currently on Aurora) given the risk of uplifting new work.
Unfortunately, this also means that ESR17 will not be the longte
On 9/3/2012 6:45 PM, qheaden wrote:
On Sunday, September 2, 2012 5:15:40 PM UTC-4, Gregory Szorc wrote:
A decision has been made: we will be using Python files executing in a
sandboxed environment (using the technique that Hanno posted).
Supporting this decision are Ted (build system owner) an
I just landed a change to how the Python virtualenv is populated during
configure. The short story is there are no more .egg-info/ directories
created in the source directory as part of virtualenv population.
These directories are no longer ignored by .hgignore and .gitignore, so
the next time
Thank you for posting this - I've become increasingly worried by the number of
real regressions that we are likely missing due to the current situation.
Like yourself I used to read every single dev.tree-management mail & try to act
on those that looked real, however after many months of not fee
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Prioritize unprioritized MemShrink bugs.
* Discuss how we measure progress.
* Discuss approaches to getting more data.
Meeting details:
* Tue, Sep 4, 2012, 4:00 PM PDT
* PB&J, Mountain View office
Our weekly DOM bindings meetings continue on Tuesday September 4th at 12:30
PM PDT. The date change is due to the US holiday on Monday. Next week
meetings will move back to their regular time and location.
Meeting details:
* Monday, September 4, 2012, 12:30 PM PDT
* No physical location
* Dial-
On Tue, Sep 04, 2012 at 01:59:29PM +0300, Aryeh Gregor wrote:
> On Tue, Sep 4, 2012 at 3:19 AM, Gregory Szorc wrote:
> > I re-ran some builds on my desktop with my instrumented build system that
> > records system metrics and an SSD clobber build was only ~50s faster than
> > the same build on a 7
On Tue, Sep 4, 2012 at 3:19 AM, Gregory Szorc wrote:
> I re-ran some builds on my desktop with my instrumented build system that
> records system metrics and an SSD clobber build was only ~50s faster than
> the same build on a 7200RPM drive. This comes out to ~5%, which isn't much.
> Both results
14 matches
Mail list logo
