On Wed, Jul 10, 2013 at 3:26 PM, Justin Lebar justin.le...@gmail.comwrote:
If I can propose something that's perhaps different:
1) Write software to figure out who's slow with reviews.
2) We talk to those people.
We've done this before too.
But we should just do it again --- the definition
We can't have a rigid rule about 24 hours. Someone requesting a review from
me on Thursday PDT probably won't get a response until Monday if neither of
us work during the weekend.
But I think it's reasonable to expect developers to process outstanding
review requests (and needinfos) at least once
On Wed, Jul 10, 2013 at 2:48 PM, Jeff Walden jwalden+...@mit.edu wrote:
Reviewer-side: I've lately tried to minimize my review turnaround time
such that I get things done, roughly FIFO, before I get a review-nag mail.
I can approximately do that, while keeping up with most of my coding.
While I think your observations are useful, I think (hope!) you are a
massive outlier and I don't think we should design a policy based on the
assumption that your review commitments are in any way normal.
I would be totally OK with a policy that explicitly applies to everyone
except you. Or, we
On Thu, Jul 11, 2013 at 6:23 AM, Justin Lebar justin.le...@gmail.comwrote:
Someone who usually has a long review queue has told me that he hates
reviewing code. I realized that we don't really have a place at Mozilla
for
experienced hackers who don't want to do reviews. Should we?
I think
The way I work is that review and needinfo requests go to my inbox and I
process them with high priority. I can and do ignore them there temporarily
if I need to. Given I use my inbox as a to-do list, that approach seems
perfect for me.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus
On Thu, Jun 27, 2013 at 3:59 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-06-26 9:09 AM, Robert O'Callahan wrote:
If we think these use cases are (or ever will be) relevant, we need to
give
feedback even if we don't plan to implement them soon. We should at least
try to make sure
On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri mou...@lamouri.fr wrote:
3. APIs solving use cases which no browser vendor shipping an engine
other Gecko is interested in at that time. In cases such as this,
Mozilla will solicit feedback from as many relevant parties as
possible, begin
On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith bsm...@mozilla.com wrote:
At the same time, I doubt such a policy is necessary or helpful for the
modules that I am owner/peer of (PSM/Necko), at least at this time. In
fact, though I haven't thought about it deeply, most of the recent evidence
I think APIs which only Mozilla is interested in at that time needs
clarification that this refers to APIs that solve use cases that only
Mozilla is interested in. If other vendors are interested in those
use-cases, but don't like our API proposal, we can't just brush that off.
Rob
--
Jtehsauts
I believe that in Webkit you're not supposed to call new directly.
Instead you call a static create method that returns the equivalent of
already_AddRefed.
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le
atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha
On Fri, May 24, 2013 at 10:50 PM, Justin Lebar justin.le...@gmail.comwrote:
If we do, we risk ending up with yet another crappy
non-solution to a real problem (see bugzilla interdiff, splinter
integration, and so on).
I think that's quite unfair to the people who integrated Splinter. It's
I'm pretty sure an unconditional mask with a linear gradient on the
right-hand-end of the text could be achieved using 'mask-box-image' and
slicing appropriately: http://www.w3.org/TR/css-masking/#the-mask-box-image.
That's not currently implemented in Gecko, but it's worth implementing.
A
Let me go on a bit of a rampage about TeX for a bit.
TeX is not a markup format. It is an executable code format. It is a
programming language by design! (It's a very poor programming language, but
let's ignore that for the moment.) You run a TeX program to generate the
rendered output. This has
On Mon, May 6, 2013 at 6:14 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
wrote my thesis which also include a lot of semantics and type theory in
FrameMaker, which was actually pretty good but is very dead.
Correction: it's alive! Amazing.
Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq
On Tue, May 7, 2013 at 7:12 AM, Benoit Jacob jacob.benoi...@gmail.comwrote:
How many specific domains will want to have their own domain-specific
markup language next? Chemistry? Biology? Electronics? Music? Flow charts?
Calligraphy?
This is a good question to ask, but I think it would help
Hopefully Web Components will provide a good solution to let authors extend
the browser with support for vocabularies that can be rendered via a
straightforward decomposition to HTML or MathML or SVG.
I think the layout requirements of MathML are too onerous for MathML to be
reduced to HTML or
On Sat, May 4, 2013 at 9:54 AM, Justin Lebar justin.le...@gmail.com wrote:
See https://bugzilla.mozilla.org/show_bug.cgi?id=809430#c39 for details.
As roc points out, this has broken |mach build dir|. Stay tuned in
the bug if you're interested in whether we resolve this by backing out
the
Hooray! Thanks for all the hard work, Stephen.
Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq
On Wed, May 1, 2013 at 8:20 PM, Andreas Gal g...@mozilla.com wrote:
We should probably start with the CPU-based fallback path. We can then try
that with SkiaGL to see what the performance looks like (the
GLContext-based implementation, essentially). Should we file a couple bugs?
I might
This is a fairly important feature that people want to get working on soon,
but there are quite a few design issues to settle on before we go too far.
I've tried to summarize the requirements, and my ideas about the design,
here:
https://wiki.mozilla.org/Gecko:AcceleratedFilters
Please tear this
On Wed, May 1, 2013 at 4:11 PM, Andreas Gal g...@mozilla.com wrote:
I wonder whether we should focus on one fast GPU path via GLSL, and have
one precise, working, I-don't-care-how-slow CPU fallback.
I agree that should be our top priority, and it may not be worth doing CPU
SIMD at all. But if
On Wed, May 1, 2013 at 5:28 PM, Andreas Gal g...@mozilla.com wrote:
Should we hide the temporary surface generation (when needed) within the
API?
GLContext::Composite(Target, Source, EffectChain, Filters)
And if multiple shaders or passes are needed, we create a temporary
surface on the
On Tue, Apr 30, 2013 at 5:32 AM, Kyle Huey m...@kylehuey.com wrote:
Is it feasible to make these functions infallible? What work would need to
be done?
Off the top of my head, I think it probably is feasible. IIRC XPCOM event
dispatch can fail for two reasons: OOM, and when the thread has
On Wed, Apr 24, 2013 at 11:21 AM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
- The 'inbound was closed for 15.3068% of the total time due to
bustage' number is an underestimate, in one sense. When inbound is
closed at 10am California time, it's a lot more inconvenient to
developers
On Tue, Apr 23, 2013 at 5:36 AM, Terrence Cole tc...@mozilla.com wrote:
Our exact rooting work is at a spot right now where we could easily use
more hands to accelerate the process. The main problem is that the work
is easy and tedious: a hard sell for pretty much any hacker at mozilla.
It
On Sat, Apr 20, 2013 at 10:34 AM, Asa Dotzler a...@mozilla.com wrote:
That would be great -- if we had a significantly larger Aurora population.
Right now, the only way to get anything close to decent did we break the
web testing is on our Beta channel.
I think Daniel was concerned about
On Sat, Apr 20, 2013 at 11:27 AM, Asa Dotzler a...@mozilla.com wrote:
I don't think it's that black and white. PDF.js and our new Cookie policy
are both user facing features and web compat concerns that need a crap ton
of compat testing.
Hmm, PDF.js yes, maybe click to play too.
But for
On Thu, Apr 18, 2013 at 3:40 AM, Ms2ger ms2...@gmail.com wrote:
On 04/17/2013 07:15 AM, Robert O'Callahan wrote:
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where
I have a request ... can we require lists in moz.build files to be in
alphabetical order, and actually enforce with some build-system check? I'm
always annoyed by Makefiles where lists are sometimes unordered and it's
hard to find items and know where to add items.
Rob
--
q“qIqfq qyqoquq
On Sun, Apr 14, 2013 at 3:40 AM, Asa Dotzler a...@mozilla.com wrote:
I have a really basic question. Is PGO's performance gains something users
are actually going to notice or are we mostly talking about synthetic
benchmark pissing contests here?
It seems to me that benchmark results affect
On Thu, Mar 28, 2013 at 9:42 AM, Bas Schouten bschou...@mozilla.com wrote:
- Improve Moz2D development workflow by having faster turnaround time on
builds and tests (both local and Try)
- Lower the barrier for external contributors, some people have already
expressed the desire to work on
On Thu, Mar 28, 2013 at 11:45 AM, Bas Schouten bschou...@mozilla.comwrote:
I don't think it works that way. At least it doesn't for me, these time
issues don't work that way. There's a context switch involved, those are
expensive and there's the feeling of pulling in 2.5 gigs+ onto your hard
On Wed, Mar 6, 2013 at 8:54 AM, Gavin Sharp ga...@gavinsharp.com wrote:
This line of reasoning can be dangerous, given the presence of
browser-specific code (e.g. if (firefox) { /* use Ci! */ }). But we're
in estimates of likelihood of bustage based on intuition territory,
which can make it
Writing a lot of performance tests creates the problem that those tests
will take a long time to run. The nature of performance tests is that each
test must run for a relatively long time to get meaningful results.
Therefore I doubt writing lots of different performance tests can scale.
(Maybe we
On Sun, Feb 24, 2013 at 1:41 PM, Neil n...@parkwaycc.co.uk wrote:
Robert O'Callahan wrote:
I suppose we could try ignoring WM_MOUSE_MOVEs when there's a Gecko event
pending, but that sounds kinda scary. I think deferring DOM mousemove
events to the next refresh driver tick would be safer
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote:
We really have to choices:
A. Provide an API that allows applications to specify whether they are
type 1 or type 2. It could be implicitly done by including a mouse event
history array.
B. Automatically prevent flooding
On Tue, Feb 19, 2013 at 8:42 PM, Justin Dolske dol...@mozilla.com wrote:
On 2/18/13 10:24 PM, Jonas Sicking wrote:
One possible solution is to allow pages to opt in to high-precision
mousemove events. Then a drawing program could do that on the
mousedown event end opt out again on mouseup.
On Tue, Feb 19, 2013 at 7:24 PM, Jonas Sicking jo...@sicking.cc wrote:
But I would expect that in the majority of other cases, each mousemove
event will not leave persisted data and dispatching more mouse moves
will simply mean that the page will redo the same calculations over
and over only.
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue, exit the anti-flood state.
This is very simple and I think it would work well for all cases. When DOM
mousemove handlers are cheap and
On Tue, Feb 19, 2013 at 11:47 AM, Karl Tomlinson mozn...@karlt.net wrote:
Robert O'Callahan writes:
How about this idea: after processing a WM_MOUSEMOVE event, go into an
anti-flood state where WM_MOUSEMOVE is ignored. After we service the
Gecko event queue, exit the anti-flood state
On Tue, Feb 19, 2013 at 12:44 PM, Karl Tomlinson mozn...@karlt.net wrote:
I don't know exactly what happens with WM_MOUSEMOVE, it would seem
unfortunate if a WM_MOUSEMOVE with an updated mouse position is
not received before key events. Changing the order of events
changes the meaning
On Tue, Feb 19, 2013 at 1:40 PM, Brian Birtles bbirt...@mozilla.com wrote:
I'm not sure if this is a relevant data point but we had an issue[1] with
touch event coalescing on fennec that produced poor results for the
following drawing application on some devices such as the Dell Streak:
On Sat, Feb 16, 2013 at 6:16 AM, Steve Fink sf...@mozilla.com wrote:
It suggests a solution where a quick handler sees all mouse move events
and batches them up, delivering the batches at a lower rate (60fps isn't
completely unreasonable). Which is of course completely not
spec-compliant.
I
On Fri, Feb 15, 2013 at 10:14 AM, Benjamin Smedberg
benja...@smedbergs.uswrote:
I think we should try to process mousemoves as quickly as we can: it's
important for certain kinds of drawing apps especially to have as much
mouse input as possible, and I doubt that only receiving mouse input at
On Fri, Feb 15, 2013 at 4:44 PM, John Volikas fero...@gmail.com wrote:
I tried the test on Nightly runnig Windows 7 64bit.
I get up to 1000(!) mousemoves per second but I have a Logitech G400
gaming mouse that defaults to a 1000Hz polling rate without Logitech's
software. I guess it depends
On Thu, Feb 14, 2013 at 3:21 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
On what OSes? Windows by default coalesces mouse move events. They are
like WM_PAINT events in that they are only delivered when the event queue
is empty. See
On Wed, Feb 13, 2013 at 6:17 AM, Jet Villegas j...@mozilla.com wrote:
I assume we would send the same diff we use for DLBI over to the
painting thread to minimize the cost.
No, the plan is to ship the entire unoptimized display list over to the
painting thread and do optimization and DLBI
On Wed, Feb 13, 2013 at 9:43 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
A large chunk of the work of off-main-thread painting is refactoring
display lists to be independent of frames, which definitely can and should
be done incrementally and could be done in parallel with the layers
On Wed, Feb 13, 2013 at 12:28 PM, Matt Woodrow mwood...@mozilla.com wrote:
This is the second half of the plan. Third paragraph of 'Proposed Solution'
The basic idea is that the display list owned by the painting thread
already contains all the information required to render the page at any
Can we compress these screenshots to JPEG or something?
Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe
Context: bug 837985.
At times we can be flooded by OS-level mousemove events. I think it would
make sense to process mousemoves at most once per refresh driver tick. This
matters for a couple of reasons: mousemove processing can cause arbitrary
JS handlers to run which can do slow things, and
On Wed, Feb 13, 2013 at 4:45 PM, Rob Arnold tell...@gmail.com wrote:
Would you want to predict the mouse location based on past events when you
dispatch the synthetic event? I guess it depends on how frequently you get
the events but this is done for touches on mobile where the input frequency
On Wed, Feb 13, 2013 at 5:14 PM, Rob Arnold tell...@gmail.com wrote:
I agree; it should be no worse than today. I do have some concerns with
dispatching a mouse move event that contains coordinates the mouse may not
have been at but the visual results for scrolling ought to be nice. Only
We're going to want to add worker bindings for canvas (both 2D and WebGL).
Over time I expect we'll want worker versions of almost every popular DOM
API that doesn't actually require content/layout. We need to be able to
share code between worker and main-thread implementations as much as
What about leaving PGO/LTCG enabled for a subset of our modules? Is that
not a possible solution?
Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever
On Thu, Jan 31, 2013 at 5:34 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
On 2013-01-30 11:11 PM, Robert O'Callahan wrote:
What about leaving PGO/LTCG enabled for a subset of our modules? Is that
not a possible solution?
I did in fact measure that by disabling PGO/LTCG on all
On Wed, Jan 23, 2013 at 4:31 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
But note that unless a given code path is examined throughout the
profiling phase of a PGO build, PGO will probably have negligible effect on
it, if any. The PGO compiler looks for hot code paths and tries to
Exactly what control do we have over what gets PGOed? In particular:
1) Are we able to exclude particular object files or libraries from PGO
when we link libxul, reducing PGO memory usage for the final link? I think
you said yes on IRC.
2) Are we able to collect a set of object files, link them
I need a big read-only buffer full of zeroes. On Linux I could mmap
/dev/zero read-only, and something similar on Windows/Mac I'm sure, but do
we already have code for that, or better yet something like that already
mapped into memory?
Rob
--
Jesus called them together and said, “You know that
One reason behind this is: what if you were using a font that wasn't free,
but had a license that required you to prevent deep-linking of the font
from other sites to where it's hosted on your site? Firefox and IE give you
a way to do that. Chrome doesn't.
In this case, it's a free font so it
I agree with what David said.
Also does anyone know if there's any research on how line lengths affect
code reading speed? For reading regular text there's definitely an optimal
line length: when text lines are too long, then when your eye moves from
the end of one line to the start of the next
On Tue, Jan 1, 2013 at 2:08 PM, Bobby Holley bobbyhol...@gmail.com wrote:
It also sounds from your initial post that other vendors weren't very
receptive to the idea. If so, that's a shame. Maybe we could try again?
I interpreted Boris to mean other vendors were apathetic rather than
opposed.
On Mon, Dec 31, 2012 at 11:23 AM, Andreas Gal g...@mozilla.com wrote:
I think it would be extremely surprising to chrome JS authors if
instanceof works differently in content and chrome, resulting in very hard
to diagnose bugs.
What if we made it work that way in content as well?
Yes,
Seems like a reasonable change to me, for the inner*, outer* and screen*
properties. I don't know about the others.
Rob
--
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you.
Bug 808466 is about changes in selection sometimes not being rendered in a
timely manner. Basically you select something and the selection doesn't
show up immediately. It will usually show up after some delay.
I *think* this is a rendering bug due to DLBI or something related, but I'm
not 100%
On Wed, Dec 19, 2012 at 12:23 AM, Dirkjan Ochtman dirk...@ochtman.nlwrote:
This sounds similar to https://bugzilla.mozilla.org/show_bug.cgi?id=801555
.
I can reproduce something via the steps in
https://bugzilla.mozilla.org/show_bug.cgi?id=801555#c16. Thanks!!!
Rob
--
Jesus called them
On Wed, Dec 19, 2012 at 2:57 AM, Kevin Gadd kevin.g...@gmail.com wrote:
Would it be possible to add some instrumentation that would let us
dive into this issue once we reproduce it - like a hotkey or toolbar
button that would start logging painting and invalidation? When I hit
this bug it is
On Fri, Dec 14, 2012 at 12:33 PM, Joshua Cranmer pidgeo...@verizon.netwrote:
3. Similar to #2, the ideal version of a reference counter would be
mozilla::Atomicnsrefcnt, mozilla::Unordered (which would make threadsafe
refcounting cheaper on our ARM platforms if we compiled with gcc 4.6 or
On Thu, Dec 13, 2012 at 6:10 AM, Jean-Marc Desperrier jmd...@gmail.comwrote:
Knowing that in most cases you will be reimplementing in parallel the
support the user has added to the OS so that native application can get it.
And doing it in parallel means never doing it perfectly the same way.
Bug 804606 is a pretty bad Flash crash that we're chasing for beta.
If you have an old-ish Mac (5 years old?) and about:support shows Intel
GMA X3100 or Intel GMA 950 under WebGL Renderer then please try
loading Yahoo mail with Flash enabled and Flash hardware acceleration
enabled. (You may need
How hard would it be to incrementally download data for the locales we need?
It seems that most users won't ever need the collation tables for Chinese,
for example. If we could figure out a way to make them available
just-in-time, that could be a win.
I assume the relevant APIs are synchronous,
On Fri, Dec 7, 2012 at 4:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Dec 7, 2012 at 4:08 PM, Norbert Lindenberg
mozillali...@lindenbergsoftware.com wrote:
This sounds like non-trivial surgery on ICU. Yes, the APIs are
synchronous. And we don't know whether the time when
On Fri, Dec 7, 2012 at 1:45 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
Bug 804606 is a pretty bad Flash crash that we're chasing for beta.
If you have an old-ish Mac (5 years old?) and about:support shows Intel
GMA X3100 or Intel GMA 950 under WebGL Renderer then please try
loading
On Wed, Nov 21, 2012 at 3:19 PM, net...@gmail.com wrote:
Maybe there's a specific case where you can reproduce this, but in general
I've always been able to set breakpoints in unnamed namespaces.
I've tested just now with a simple app in VS2008, VS2010 and VS2012. And
on those debuggers it
On Wed, Nov 21, 2012 at 4:07 PM, net...@gmail.com wrote:
In VS2010 you can have symbols in your watch window that are in an
anonymous namespace and you can put breakpoints on them. For example:
namespace {
int g = 42;
}
In your Watch window, add g, and you can see 42.
If you have an
On Mon, Nov 12, 2012 at 8:37 PM, Jeff Walden jwalden+...@mit.edu wrote:
We ended up removing the nested |using| above and making all SpiderMonkey
headers qualify everything with mozilla::. We use few enough things from
mozilla:: so far that we switched to |using mozilla::RangedPtr| and so on
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg za...@panix.com wrote:
The scenario I'm concerned with is when a .cpp file does 'using namespace
A;' and then goes on to define a bunch of its *own* symbols; later someone
adds a symbol to namespace A, and gets an unexpected break possibly miles
On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com wrote:
The style guide should forbid `using namespace` altogether. Use only what
you need.
I really don't think it should. I do not want to see source files full of
difficult-to-maintain and unnecessary using boilerplate a la
On Fri, Nov 2, 2012 at 2:19 PM, Dave Mandelin dmande...@gmail.com wrote:
(b) Failing that, how about not fixing PGO bugs unless they are
reproducible, on a trial basis? If my lifecycle theory is correct, then the
total crash rate would stay roughly constant. And I assume that if the
crash
On Fri, Nov 2, 2012 at 2:53 PM, Dave Mandelin dmande...@gmail.com wrote:
Sure, it's not some grand thing. I just like things to be nicely
organized. And I really did find mochitest paths a hassle and a (small) tax
on development effort.
You could keep tests near the code and still have a
On Tue, Oct 30, 2012 at 1:13 PM, Nicholas Nethercote n.netherc...@gmail.com
wrote:
#pragma once does have one drawback (other than being non-standard)
and that is if you have the same file in different locations (we have
this because our build system copies files around) then the compiler
On Sat, Oct 13, 2012 at 3:25 AM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
In some cases in the past (such as bug 563082), we've needed to change the
semantics of some of the NSPR functions to make them work better for some
things, such as more precise time measurements, but we've had to
I guess 7 digits of precision beyond the decimal point is overkill.
How about we output values rounded to the nearest 1e-6.
Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be
On Tue, Oct 9, 2012 at 10:16 AM, Anthony Jones ajo...@mozilla.com wrote:
This formats the float to 6 significant figures, however a float has 7.2
significant figures[1]. A float can contain any integer up to 2^24.
Anything more than 999,999 pixels shows in exponent format as 1e+6 and so
on.
On Thu, Aug 30, 2012 at 1:00 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote:
I agree with that if we talk about performance in general. But this
thread is about specific regressions in performance as a result of
changeset going into our tree. I don't think the same argument applies
here,
On Wed, Aug 29, 2012 at 6:17 AM, L. David Baron dba...@dbaron.org wrote:
We don't want to be running our reftests at
a size smaller than the accepted max size for reftests at W3C.
What is the current required size for W3C reftests? I can't find any
documentation of that.
Rob
--
“You have
On Tue, Aug 28, 2012 at 8:20 AM, Alex Keybl ake...@mozilla.com wrote:
Quick ping to platform devs - do you all know of any particularly risky
changes going in over the next 6 weeks that carry the possibility of
regression, especially to B2G? Thanks in advance!
On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum bhear...@mozilla.com wrote:
On 08/22/12 04:38 PM, Gregory Szorc wrote:
Let's think of what can be done to secure/limit Python. Disabling import
has already been mentioned. That's a start.
I think it's worth noting that even if you *do* limit
301 - 389 of 389 matches
Mail list logo
