On Tue, Jun 25, 2013 at 6:08 AM, 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
On Fri, Jun 21, 2013 at 11:45 PM, Andrew Overholt overh...@mozilla.com wrote:
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy
I'd appreciate your review feedback. Thanks.
Thank you for putting this together.
In general, I'd like the point no prefixing to be made more
Robert O'Callahan wrote:
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,
Henri Sivonen wrote:
On Tue, Jun 25, 2013 at 6:08 AM, 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
I don't really think there is a controversy here network wise - mostly
applicability is a case of I know it when I see it and the emphasis here
is on things that are exposed at the webdev level is the right thing.
Sometimes that's markup, sometimes that's header names which can touch on
core
On Tue, Jun 25, 2013 at 11:11 PM, Brian Smith bsm...@mozilla.com wrote:
If it is intended that the stuff I work on (networking protocols, security
protocols, and network security protocols) be covered by the policy, then I
will reluctantly debate that after the end of the quarter. (I have
Hi,
I intent to implement an extension to nsIDOMMozICCManager.
When unlocking a SIM card, there is a maximum number of remaining tries.
The new interface 'getCardLockRetryCount' will allow for reading the
number of remaining tries for a specific lock. During the unlock
process, an app can
On 21/06/13 21:45, Andrew Overholt wrote:
I'd appreciate your review feedback. Thanks.
Thank you for putting this together.
I am going to quote some parts of the document to give some context to
my comments.
Note that at this time, we are specifically focusing on new JS APIs
and not on
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 2013-06-25 1:42 PM, Clint Talbert wrote:
On 6/24/2013 8:02 PM, Justin Lebar wrote:
Under what circumstances would you expect the code coverage build to
break but all our other builds to remain green?
Sorry, I should have been more clear. For builds, I think it would be
pretty unusual for
tl;dr You may experience a change in behavior in build performance
In bug 884587, we just changed how file purging occurs during builds.
Due to historical reasons (notably bad build dependencies and to prevent
old files from leaking into the distribution package), we wipe out large
parts of
On Monday 2013-06-24 18:50 -0700, Clint Talbert wrote:
So, the key things I want to know:
* Will you support code coverage? Would it be useful to your work to
have a regularly scheduled code coverage build test run?
* Would you want to additionally consider using something like
JS-Lint for
On 2013-06-25 2:52 PM, Gregory Szorc wrote:
tl;dr You may experience a change in behavior in build performance
In bug 884587, we just changed how file purging occurs during builds.
FWIW this has been backed out for now.
Cheers,
Ehsan
___
On Mon, Jun 24, 2013 at 08:02:26PM -0700, Justin Lebar wrote:
Under what circumstances would you expect the code coverage build to break
but all our other builds to remain green?
Anywhere you're using -Werror. I ran into this in a past life with
GCC's may-use-uninitialized warning; if it's
On Tue, Jun 25, 2013 at 1:40 PM, L. David Baron dba...@dbaron.org wrote:
On Monday 2013-06-24 18:50 -0700, Clint Talbert wrote:
So, the key things I want to know:
* Will you support code coverage? Would it be useful to your work to
have a regularly scheduled code coverage build test run?
Posted this to dev.planning as well.
We in QA have been discussing ways to help improve our workflows and provide
some standardization across the teams in how we use Bugzilla. As part of this
process we have come up with a proposal to make a small change to the
definition of qawanted
during the first 12 months of development of new user-facing
products, APIs that have not yet been embraced by other vendors or
thoroughly discussed by standards bodies may be shipped only as a part
of this product, thus clearly indicating their lack of standardization
and limiting any market
On Tue, Jun 25, 2013 at 11:52:03AM -0700, Gregory Szorc wrote:
tl;dr You may experience a change in behavior in build performance
In bug 884587, we just changed how file purging occurs during builds.
Due to historical reasons (notably bad build dependencies and to
prevent old files from
Hello fellow hackers,
There are plugin related test failures on inbound and aurora. I've filed
bug 887094 about this and have consequently closed central, inbound, birch
and aurora.
I don't know where to start to help with this myself. Hopefully someone in
the know will jump on board soon.
19 matches
Mail list logo
