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.
Che
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 fr
"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 shar
On 2013-06-25 6:07 PM, Kyle Huey wrote:
On Tue, Jun 25, 2013 at 1:40 PM, L. David Baron 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 coverag
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 keyword
On Tue, Jun 25, 2013 at 1:40 PM, L. David Baron 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?
> > * Woul
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 st
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
___
dev-platfo
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
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 ob
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 t
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 them to break on code coverage and yet remai
On Wed, Jun 26, 2013 at 4:15 AM, Mounir Lamouri 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 the standard
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 C
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 dis
On Tue, Jun 25, 2013 at 11:11 PM, Brian Smith 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 many
> things to f
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 prot
Henri Sivonen wrote:
> On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith 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
>
Robert O'Callahan wrote:
> On Tue, Jun 25, 2013 at 3:08 PM, Brian Smith 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 r
On Tue, Jun 25, 2013 at 10:01:15AM +0300, Henri Sivonen wrote:
> On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith 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
> > h
On Fri, Jun 21, 2013 at 11:45 PM, Andrew Overholt 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
forcefully/clearly.
Further
On Tue, Jun 25, 2013 at 6:08 AM, Brian Smith 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've observed
> in
22 matches
Mail list logo
