Travel Portal India – i2space.com is a leading online travel portal in India.
We provide Travel portal Development to travel consultation, searching for trip
plans, seat layout, providing customized tour packages, booking tickets, etc.
For more details please visit our website
http://www.i2spa
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote:
> On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote:
> > We've dropped support for versions of MSVC prior to 2010, and we're
> > requiring at least GCC 4.4. According to [0] that means we should
> > be able to use *auto*. Anybod
On 7/17/2013 2:05 AM, Jesse Ruderman wrote:
>
> AWSY is not a replacement for shutdown-leak testing. It's limited to code
> exercised by TP5. Small leaks are masked by normal variation in memory use.
>
>
Note, though, that we still run almost all of our test suites on debug
builds with leak chec
I've only quickly glanced at those, and I haven't followed those
discussions at all, I have to admit.
Are there any practical consequences for gecko/firefox? It doesn't look
like it would, in particular when looking at the reference
implementations being all on top of html platforms.
Axel
O
On 7/16/2013 7:12 PM, L. David Baron wrote:
The W3C has released three RDFA-related documents, one proposed
recommendation:
HTML+RDFa 1.1:
http://www.w3.org/TR/2013/PR-html-rdfa-20130625/
If there are comments you think Mozilla should send as part of the
review, or if you think Mozilla
I'll keep this short. There are changes to the meeting locations for the
Engineering/Platform (Tue, 11am PT) meeting.
SFO: Warfield (change to provide more space)
TOR: Finch (change to avoid conflict with TOR Commons)
MTV: Warp Core (no change)
Remote: Engineering Vidyo room (no change)
Lawrence
On 7/17/2013 4:26 AM, Ted Mielczarek wrote:
The only valuable thing we're losing from shutting this off is
tracemalloc coverage, which we don't have elsewhere. I don't have any
evidence to show that anyone has actually looked at the tracemalloc data
or done anything useful with it in recent histo
> So the main thing we'd lose is graph server monitoring of Trace Malloc Leaks.
> This is occasionally useful, but in a limited way because the monitoring
> process is unowned, and because the current value of the benchmark is high
> enough that small changes are ignored by the monitoring syste
Traditionally, it's been very difficult for the build peers to keep on
top of changes in the build config because changes are occurring on bug
components we don't follow, are touching files all over the tree, and
because build peers aren't always asked for review.
The potential for "sneaking" thin
The flip side of this, of course, is that build peers need to ensure
that they are not the long pole in reviews. But I presume you guys
are prepared to turn around these additional reviews quickly,
otherwise you wouldn't have asked for the extra load.
On Wed, Jul 17, 2013 at 5:00 PM, Gregory Szor
On 7/17/2013 5:24 PM, Justin Lebar wrote:
> The flip side of this, of course, is that build peers need to ensure
> that they are not the long pole in reviews. But I presume you guys
> are prepared to turn around these additional reviews quickly,
> otherwise you wouldn't have asked for the extra lo
Hi,
As it seems there is a trend towards using in-tree mozconfigs for local
developer builds, I think a reminder is in order:
In-tree mozconfigs are for buildbot consumption.
For Firefox desktop builds, a mozconfig should be unnecessary for most
people, except if their compiler is not at
On Thu, Jul 18, 2013 at 10:51:10AM +0900, Mike Hommey wrote:
> Hi,
>
> As it seems there is a trend towards using in-tree mozconfigs for
> local developer builds, I think a reminder is in order:
>
> In-tree mozconfigs are for buildbot consumption.
>
> For Firefox desktop builds, a mozcon
I'm probably responsible for those Fennec build files (if they were
correct, it would have been blassey).
In any case, we probably did 'sneak' things past build peers. Not
intentionally, of course.
We were more worried about getting a product into the marketplace that
didn't suck than the c
On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey wrote:
> Hi,
>
> As it seems there is a trend towards using in-tree mozconfigs for local
> developer builds, I think a reminder is in order:
>
> In-tree mozconfigs are for buildbot consumption.
>
> For Firefox desktop builds, a mozconfig should
On Wed, Jul 17, 2013 at 10:29:01PM -0700, Dave Townsend wrote:
> On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey wrote:
>
> > Hi,
> >
> > As it seems there is a trend towards using in-tree mozconfigs for
> > local developer builds, I think a reminder is in order:
> >
> > In-tree mozconfigs a
The proposal sounds good to me but I guess you wouldn't want to be
notified of every small addition/change to Makefiles in test
directories? I suppose you're targeting actual changes to dependencies
etc, but where do we draw the line?
Can we maybe add a push hook intelligent enough to separate act
17 matches
Mail list logo
